fix prefixes and add smq contrib file

Signed-off-by: Musilah <[email protected]>

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,4 +1,4 @@
-Pull request title should be `MG-XXX - description` or `NOISSUE - description` where XXX is ID of issue that this PR relate to.
+Pull request title should be `SMQ-XXX - description` or `NOISSUE - description` where XXX is ID of issue that this PR relate to.
 Please review the [CONTRIBUTING.md](./CONTRIBUTING.md) file for detailed contributing guidelines.
 
 ### What does this do?

CONTRIBUTING.md

@@ -53,11 +53,11 @@ git checkout main
 git pull --rebase upstream main
 ```
 
-Create a new topic branch from `main` using the naming convention `MG-[issue-number]`
+Create a new topic branch from `main` using the naming convention `SMQ-[issue-number]`
 to help us keep track of your contribution scope:
 
 ```
-git checkout -b MG-[issue-number]
+git checkout -b SMQ-[issue-number]
 ```
 
 Commit your changes in logical chunks. When you are ready to commit, make sure
@@ -80,7 +80,7 @@ git pull --rebase upstream main
 Push your topic branch up to your fork:
 
 ```
-git push origin MG-[issue-number]
+git push origin SMQ-[issue-number]
 ```
 
 [Open a Pull Request](https://help.github.com/articles/using-pull-requests/) with a clear title

blog/oauth/oauth.md

@@ -66,10 +66,10 @@ Currently, we have implemented the OAuth2.0 authorization code flow with Google
 
    ```env
    ### Google OAuth2
-   MG_GOOGLE_CLIENT_ID="01234567-8abc0defg7hijklmnopqr23456s78tu9.apps.googleusercontent.com"
-   MG_GOOGLE_CLIENT_SECRET="GOCSPX-_abCDEfG1hIJKl4MnO7pQRSTuvwxyz"
-   MG_GOOGLE_REDIRECT_URL="http://localhost/oauth/callback/google"
-   MG_GOOGLE_STATE="7NN28jSDAg4z"
+   SMQ_GOOGLE_CLIENT_ID="01234567-8abc0defg7hijklmnopqr23456s78tu9.apps.googleusercontent.com"
+   SMQ_GOOGLE_CLIENT_SECRET="GOCSPX-_abCDEfG1hIJKl4MnO7pQRSTuvwxyz"
+   SMQ_GOOGLE_REDIRECT_URL="http://localhost/oauth/callback/google"
+   SMQ_GOOGLE_STATE="7NN28jSDAg4z"
    ```
 
    The state is a secret key that is shared between the client and the server. It is used to prevent CSRF attacks. The state should be a random string and should be kept secret. The state is used to verify the integrity of the response from the authorization server.

docs/authentication.md

@@ -25,22 +25,22 @@ The following actions are supported:
 Federated authentication is a process of authenticating users using external identity providers. SuperMQ supports federated authentication using [OpenID Connect][oidc] protocol. SuperMQ is a resource provider and it uses [Google Identity Platform][google-identity-platform] as an identity provider. To use federated authentication, you need to create a project in Google Cloud Platform and enable Google Identity Platform API. After that, you need to create OAuth 2.0 credentials and configure the consent screen. This can be done by following Google's [documentation][google-identity-platform-docs]. Once you have created OAuth 2.0 credentials, you need to set the following environment variables:
 
 ```bash
-MG_USERS_GOOGLE_CLIENT_ID=985229335584-m2mft8lqbgfn5gfw9ftrm3r2sgu4tsrw.apps.googleusercontent.com
-MG_USERS_GOOGLE_CLIENT_SECRET=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YUIpw
-MG_UI_GOOGLE_REDIRECT_URL=http://localhost/google-callback
-MG_USERS_GOOGLE_STATE=pGXVNhEeKfycuBzk5InlSfMlEU9UrhlkTUOSqhsgDzXP2Y4RsN
-MG_USERS_UI_REDIRECT_URL=http://localhost:9090
+SMQ_USERS_GOOGLE_CLIENT_ID=985229335584-m2mft8lqbgfn5gfw9ftrm3r2sgu4tsrw.apps.googleusercontent.com
+SMQ_USERS_GOOGLE_CLIENT_SECRET=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YUIpw
+SMQ_UI_GOOGLE_REDIRECT_URL=http://localhost/google-callback
+SMQ_USERS_GOOGLE_STATE=pGXVNhEeKfycuBzk5InlSfMlEU9UrhlkTUOSqhsgDzXP2Y4RsN
+SMQ_USERS_UI_REDIRECT_URL=http://localhost:9090
 ```
 
-1. `MG_USERS_GOOGLE_CLIENT_ID` - Google OAuth 2.0 client ID
-2. `MG_USERS_GOOGLE_CLIENT_SECRET` - Google OAuth 2.0 client secret
-3. `MG_UI_GOOGLE_REDIRECT_URL` - Google OAuth 2.0 redirect URL to handle callback after successful authentication. This URL must be registered in the Google Cloud Platform.
-4. `MG_USERS_GOOGLE_STATE` - Random string used to protect against cross-site request forgery attacks.
-5. `MG_USERS_UI_REDIRECT_URL` - URL to redirect user after successful authentication. This can be your SuperMQ UI URL.
+1. `SMQ_USERS_GOOGLE_CLIENT_ID` - Google OAuth 2.0 client ID
+2. `SMQ_USERS_GOOGLE_CLIENT_SECRET` - Google OAuth 2.0 client secret
+3. `SMQ_UI_GOOGLE_REDIRECT_URL` - Google OAuth 2.0 redirect URL to handle callback after successful authentication. This URL must be registered in the Google Cloud Platform.
+4. `SMQ_USERS_GOOGLE_STATE` - Random string used to protect against cross-site request forgery attacks.
+5. `SMQ_USERS_UI_REDIRECT_URL` - URL to redirect user after successful authentication. This can be your SuperMQ UI URL.
 
 SuperMQ handles the authentication callback at `<MG_BASE_URL>/google-callback` endpoint, where `<MG_BASE_URL>` is the base URL of your SuperMQ instance. This endpoint needs to be registered in the Google Cloud Platform and it must match the value of `MG_UI_GOOGLE_REDIRECT_URL` environment variable. If an error occurs, the error message is sent from the backend using a query paramters with the key `error`. The UI will read the error message from the query parameter and display it to the user. When a user signs up, SuperMQ creates a local copy of the user with an ID provided by Google, the name and email address provided by Google and the password is left empty as the user is authenticated using Google, i.e. external user. The user can be created only once, so if the user already exists, the error will be sent to the UI via the error cookie. Finally, the user is redirected to the URL provided in `MG_USERS_UI_REDIRECT_URL` environment variable upon successful authentication. This should be the base URL of your UI.
 
-The `MG_USERS_GOOGLE_CLIENT_ID`, `MG_USERS_GOOGLE_CLIENT_SECRET`, `MG_UI_GOOGLE_REDIRECT_URL` and `MG_USERS_GOOGLE_STATE` environment variables should be the same for the UI and users service. The `MG_USERS_UI_REDIRECT_URL` environment variable should be the URL of your UI which is used to redirect the user after successful authentication.
+The `SMQ_USERS_GOOGLE_CLIENT_ID`, `SMQ_USERS_GOOGLE_CLIENT_SECRET`, `SMQ_UI_GOOGLE_REDIRECT_URL` and `SMQ_USERS_GOOGLE_STATE` environment variables should be the same for the UI and users service. The `SMQ_USERS_UI_REDIRECT_URL` environment variable should be the URL of your UI which is used to redirect the user after successful authentication.
 
 SuperMQ uses the `access_token` provided by Google only to fetch user information which includes user id, name, given name, family name, picture and locale. The `access_token` is not stored in the database and it's not used for any other purpose. The `id_token` is not used as it presents challenges on refreshing it, thus SuperMQ issues its own `access_token` and `refresh_token` stored in the HTTP-only cookie and it's used to authenticate the user in the subsequent requests.
 

docs/authorization.md

@@ -771,5 +771,5 @@ There are two ways to user get registered to SuperMQ, self-register and register
 User registration is self register default which can be changed by following environment variable:
 
 ```env
-MG_USERS_ALLOW_SELF_REGISTER=true
+SMQ_USERS_ALLOW_SELF_REGISTER=true
 ```

docs/bootstrap.md

@@ -126,7 +126,7 @@ In order to disconnect, the same request should be sent with the value of `state
 
 - *Encrypt the external key.*
 
-First, encrypt the external key of your thing using AES encryption. The encryption key is specified by the `MG_BOOTSTRAP_ENCRYPT_KEY` environment variable. Use a library or utility that supports AES encryption to do this. Here's an example of how to encrypt using Go:
+First, encrypt the external key of your thing using AES encryption. The encryption key is specified by the `SMQ_BOOTSTRAP_ENCRYPT_KEY` environment variable. Use a library or utility that supports AES encryption to do this. Here's an example of how to encrypt using Go:
 
 ```go
 package main
@@ -175,7 +175,7 @@ func main() {
 }
 ```
 
-Replace `<external_key>` and `<crypto_key>` with the thing's external key and `MG_BOOTSTRAP_ENCRYPT_KEY` respectively.
+Replace `<external_key>` and `<crypto_key>` with the thing's external key and `SMQ_BOOTSTRAP_ENCRYPT_KEY` respectively.
 
 - *Make a request to the bootstrap service.*
 

docs/certs.md

@@ -16,7 +16,7 @@ Certificate service can create certificates in PKI mode - where certificates iss
 
 ### PKI mode
 
-When `MG_CERTS_VAULT_HOST` is set, it is presumed that `Vault` is installed and `certs` service will issue certificates using `Vault` API.
+When `SMQ_CERTS_VAULT_HOST` is set, it is presumed that `Vault` is installed and `certs` service will issue certificates using `Vault` API.
 
 First you'll need to set up `Vault`.
 
@@ -25,10 +25,10 @@ To setup `Vault` follow steps in [Build Your Own Certificate Authority (CA)][vau
 To setup certs service with `Vault` following environment variables must be set:
 
 ```bash
-MG_CERTS_VAULT_HOST=vault-domain.com
-MG_CERTS_VAULT_PKI_PATH=<vault_pki_path>
-MG_CERTS_VAULT_ROLE=<vault_role>
-MG_CERTS_VAULT_TOKEN=<vault_acces_token>
+SMQ_CERTS_VAULT_HOST=vault-domain.com
+SMQ_CERTS_VAULT_PKI_PATH=<vault_pki_path>
+SMQ_CERTS_VAULT_ROLE=<vault_role>
+SMQ_CERTS_VAULT_TOKEN=<vault_acces_token>
 ```
 
 For lab purposes you can use docker-compose and script for setting up PKI in [meodor-vault][meodor-vault].

docs/dev-guide.md

@@ -235,11 +235,11 @@ nats-server
 ```
 
 If you want to change the default message broker to [RabbitMQ][rabbitmq], [VerneMQ][vernemq] or [Kafka][kafka] you need to install it on the local system.
-To run using a different broker you need to set the `MG_BROKER_TYPE` env variable to `nats`, `rabbitmq` or `vernemq` during make and run process.
+To run using a different broker you need to set the `SMQ_BROKER_TYPE` env variable to `nats`, `rabbitmq` or `vernemq` during make and run process.
 
 ```bash
-MG_BROKER_TYPE=<broker-type> make
-MG_BROKER_TYPE=<broker-type> make run
+SMQ_BROKER_TYPE=<broker-type> make
+SMQ_BROKER_TYPE=<broker-type> make run
 ```
 
 #### PostgreSQL

docs/lora.md

@@ -22,7 +22,7 @@ Once everything is installed, execute the following command from the LoRa Server
 docker-compose up
 ```
 
-**Troubleshouting:** SuperMQ and LoRa Server use their own MQTT brokers which by default occupy MQTT port `1883`. If both are ran on the same machine different ports must be used. You can fix this on SuperMQ side by configuring the environment variable `MG_MQTT_ADAPTER_MQTT_PORT`.
+**Troubleshouting:** SuperMQ and LoRa Server use their own MQTT brokers which by default occupy MQTT port `1883`. If both are ran on the same machine different ports must be used. You can fix this on SuperMQ side by configuring the environment variable `SMQ_MQTT_ADAPTER_MQTT_PORT`.
 
 ## Setup LoRa Server
 
@@ -46,9 +46,9 @@ Once everything is running and the LoRa Server is provisioned, execute the follo
 docker-compose -f docker/addons/lora-adapter/docker-compose.yml up -d
 ```
 
-**Troubleshouting:** The lora-adapter subscribes to the LoRa Server MQTT broker and will fail if the connection is not established. You must ensure that the environment variable `MG_LORA_ADAPTER_MESSAGES_URL` is propertly configured.
+**Troubleshouting:** The lora-adapter subscribes to the LoRa Server MQTT broker and will fail if the connection is not established. You must ensure that the environment variable `SMQ_LORA_ADAPTER_MESSAGES_URL` is propertly configured.
 
-**Remark:** By defaut, `MG_LORA_ADAPTER_MESSAGES_URL` is set as `tcp://lora.mqtt.supermq.io:1883` in the [docker-compose.yml][lora-docker-compose] file of the adapter. If you run the composition without configure this variable you will start to receive messages from our demo server.
+**Remark:** By defaut, `SMQ_LORA_ADAPTER_MESSAGES_URL` is set as `tcp://lora.mqtt.supermq.io:1883` in the [docker-compose.yml][lora-docker-compose] file of the adapter. If you run the composition without configure this variable you will start to receive messages from our demo server.
 
 ### Route Map
 
@@ -87,10 +87,10 @@ The lora-adapter uses the matadata of provision events emitted by SuperMQ system
 
 To forward LoRa messages the lora-adapter subscribes to topics `applications/+/devices/+` of the LoRa Server MQTT broker. It verifies the `app_id` and the `dev_eui` of received messages. If the mapping exists it uses corresponding `Channel ID` and `Thing ID` to sign and forwards the content of the LoRa message to the SuperMQ message broker.
 
-[lora-adapter]: https://github.com/absmach/supermq/tree/main/lora
+[lora-adapter]: https://github.com/absmach/smq-contrib/tree/main/lora
 [lora-server]: https://www.loraserver.io
 [lora-gateway]: https://www.loraserver.io/lora-gateway-bridge/overview/
 [semtech]: https://github.com/Lora-net/packet_forwarder/blob/master/PROTOCOL.TXT
 [lora-app-server]: https://www.loraserver.io/lora-app-server/overview/
-[lora-docker-compose]: https://github.com/absmach/supermq/blob/main/docker/addons/lora-adapter/docker-compose.yml
+[lora-docker-compose]: https://github.com/absmach/smq-contrib/blob/main/docker/lora-adapter/docker-compose.yml
 [redis]: https://redis.io/

docs/messaging.md

@@ -300,13 +300,13 @@ Each broker has a unique profile for configuration. The available profiles are:
 The following command will run VerneMQ as an MQTT broker and Nats as a message broker:
 
 ```bash
-MG_MQTT_BROKER_TYPE=vernemq MG_BROKER_TYPE=nats make run
+SMQ_MQTT_BROKER_TYPE=vernemq SMQ_BROKER_TYPE=nats make run
 ```
 
 The following command will run NATS as an MQTT broker and RabbitMQ as a message broker:
 
 ```bash
-MG_MQTT_BROKER_TYPE=nats MG_BROKER_TYPE=rabbitmq make run
+SMQ_MQTT_BROKER_TYPE=nats SMQ_BROKER_TYPE=rabbitmq make run
 ```
 
 By default, NATS is used as an MQTT broker and RabbitMQ as a message broker.
@@ -358,26 +358,26 @@ SuperMQ supports [NATS][nats], [RabbitMQ][rabbitmq] and [Kafka][kafka] as messag
 
 ### NATS JetStream
 
-Since SuperMQ supports configurable message brokers, you can use Nats with JetStream enabled as a message broker. To do so, you need to set `MG_BROKER_TYPE` to `nats` and set `MG_NATS_URL` to the url of your nats instance. When using `make` command to start SuperMQ `MG_BROKER_URL` is automatically set to `MG_NATS_URL`.
+Since SuperMQ supports configurable message brokers, you can use Nats with JetStream enabled as a message broker. To do so, you need to set `SMQ_BROKER_TYPE` to `nats` and set `SMQ_NATS_URL` to the url of your nats instance. When using `make` command to start SuperMQ `SMQ_BROKER_URL` is automatically set to `SMQ_NATS_URL`.
 
 Since SuperMQ is using `nats:2.9.21-alpine` docker image with the following configuration:
 
 ```conf
 max_payload: 1MB
 max_connections: 1M
-port: $MG_NATS_PORT
-http_port: $MG_NATS_HTTP_PORT
+port: $SMQ_NATS_PORT
+http_port: $SMQ_NATS_HTTP_PORT
 trace: true
 
 jetstream {
     store_dir: "/data"
     cipher: "aes"
-    key: $MG_NATS_JETSTREAM_KEY
+    key: $SMQ_NATS_JETSTREAM_KEY
     max_mem: 1G
 }
 ```
 
-These are the default values but you can change them by editing the configuration file. For more information about nats configuration checkout [official nats documentation][nats-jestream]. The health check endpoint is exposed on `MG_NATS_HTTP_PORT` and its `/healthz` path.
+These are the default values but you can change them by editing the configuration file. For more information about nats configuration checkout [official nats documentation][nats-jestream]. The health check endpoint is exposed on `SMQ_NATS_HTTP_PORT` and its `/healthz` path.
 
 #### Architecture
 
@@ -387,9 +387,9 @@ This versatile architecture allows you to use nats alone for the MQTT broker, me
 
 ### RabbitMQ
 
-Since SuperMQ uses a configurable message broker, you can use RabbitMQ as a message broker. To do so, you need to set `MG_BROKER_TYPE` to `rabbitmq` and set `MG_RABBITMQ_URL` to the url of your RabbitMQ instance. When using `make` command to start SuperMQ `MG_BROKER_URL` is automatically set to `MG_RABBITMQ_URL`.
+Since SuperMQ uses a configurable message broker, you can use RabbitMQ as a message broker. To do so, you need to set `SMQ_BROKER_TYPE` to `rabbitmq` and set `SMQ_RABBITMQ_URL` to the url of your RabbitMQ instance. When using `make` command to start SuperMQ `SMQ_BROKER_URL` is automatically set to `SMQ_RABBITMQ_URL`.
 
-Since SuperMQ is using `rabbitmq:3.9.20-management-alpine` docker image, the management console is available at port `MG_RABBITMQ_HTTP_PORT`
+Since SuperMQ is using `rabbitmq:3.9.20-management-alpine` docker image, the management console is available at port `SMQ_RABBITMQ_HTTP_PORT`
 
 #### Architecture
 
@@ -412,7 +412,7 @@ For more information and examples checkout [official nats.io documentation][nats
 
 ### Kafka
 
-Since SuperMQ uses a configurable message broker, you can use Kafka as a message broker. To do so, you need to set `MG_BROKER_TYPE` to `kafka` and set `MG_KAFKA_URL` to the url of your Kafka instance. When using `make` command to start SuperMQ `MG_BROKER_URL` is automatically set to `MG_KAFKA_URL`.
+Since SuperMQ uses a configurable message broker, you can use Kafka as a message broker. To do so, you need to set `SMQ_BROKER_TYPE` to `kafka` and set `SMQ_KAFKA_URL` to the url of your Kafka instance. When using `make` command to start SuperMQ `SMQ_BROKER_URL` is automatically set to `SMQ_KAFKA_URL`.
 
 SuperMQ utilizes `spotify/kafka:latest` docker image. The image also exposes `kafka:9092` and `zookeeper:2181` ports. This is used for development purposes only. For production, it is assumed that you have your own Kafka cluster.
 
@@ -441,7 +441,7 @@ For more information and examples checkout [official nats.io documentation][nats
 [mqttjs]: https://github.com/mqttjs/MQTT.js
 [websocket-client]: http://www.hivemq.com/demos/websocket-client/
 [nats]: https://nats.io/documentation/writing_applications/subscribing/
-[rabbitmq]: https://www.rabbitmq.com/documentation.html
+https://github.com/absmach/supermq/blob/main/api/openapi/readers.yml: https://www.rabbitmq.com/documentation.html
 [vernemq]: https://docs.vernemq.com/
 [kafka]: https://kafka.apache.org/documentation/
 [nats-mqtt]: https://docs.nats.io/running-a-nats-service/configuration/mqtt

docs/opcua.md

@@ -117,7 +117,7 @@ The OPC-UA adapter can be used in an industrial setup to monitor process values
 
 Things on SuperMQ can be created to represent these devices and the channels can be created to represent the data points on the devices. The OPC-UA adapter can then be used to subscribe to the OPC-UA server and forward the data to the NATS message broker. This data can then be consumed by other services in the SuperMQ system, and further processing done if need be.
 
-[opcua-adapter]: https://github.com/absmach/supermq/tree/main/opcua
+[opcua-adapter]: https://github.com/absmach/smq-contrib/tree/main/opcua
 [opcua-arch]: https://en.wikipedia.org/wiki/OPC_Unified_Architecture
 [public-opcua]: https://github.com/node-opcua/node-opcua/wiki/publicly-available-OPC-UA-Servers-and-Clients
 [redis]: https://redis.io/