NOISSUE - Rename Mainflux to Magistrala (#178)

* Updated cli usage command Signed-off-by: JeffMboya <[email protected]> * Updated cli usage command Signed-off-by: JeffMboya <[email protected]> * Updated cli usage command Signed-off-by: JeffMboya <[email protected]> * Updated cli usage Signed-off-by: JeffMboya <[email protected]> * Renamed mainflux to magistrala Signed-off-by: JeffMboya <[email protected]> * Start ignoring config.toml * Removed config.toml file Signed-off-by: JeffMboya <[email protected]> * Start ignoring config.toml * Renamed mainflux to magistrala Signed-off-by: JeffMboya <[email protected]> * Fixed URLs Signed-off-by: JeffMboya <[email protected]> * Fixed URLs Signed-off-by: JeffMboya <[email protected]> * Fixed Typos Signed-off-by: JeffMboya <[email protected]> * Reverted changes to events.md Signed-off-by: JeffMboya <[email protected]> * Reverted changes to events.md Signed-off-by: JeffMboya <[email protected]> * Reverted changes to events.md Signed-off-by: JeffMboya <[email protected]> * Updated services health check Signed-off-by: JeffMboya <[email protected]> * reverted changes to codeowners Signed-off-by: JeffMboya <[email protected]> * Updated codeowners Signed-off-by: JeffMboya <[email protected]> * Updated codeowners Signed-off-by: JeffMboya <[email protected]> * Updated codeowners Signed-off-by: JeffMboya <[email protected]> * Updated codeowners Signed-off-by: JeffMboya <[email protected]> * Updated provision.md Signed-off-by: JeffMboya <[email protected]> --------- Signed-off-by: JeffMboya <[email protected]>
absmach · Mar 20, 2024 · 16bb5a9 · 16bb5a9
1 parent 111f0dc
commit 16bb5a9
Show file tree

Hide file tree

Showing 20 changed files with 381 additions and 371 deletions.
diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
@@ -1 +1 @@
-*   @mainflux/maintainers
+*   @absmach/maintainers
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -1,7 +1,7 @@
 # Contributing to Magistrala
 
 The following is a set of guidelines to contribute to Magistrala and its libraries, which are
-hosted on the [Magistrala Organization](https://github.com/mainflux) on GitHub.
+hosted on the [Magistrala Organization](https://github.com/absmach/magistrala) on GitHub.
 
 This project adheres to the [Contributor Covenant 1.2](http://contributor-covenant.org/version/1/2/0).
 By participating, you are expected to uphold this code. Please report unacceptable behavior to
@@ -13,7 +13,7 @@ Reporting issues are a great way to contribute to the project. We are perpetuall
 thorough bug report.
 
 Before raising a new issue, check [our issue
-list](https://github.com/mainflux/docs/issues) to determine if it already contains the
+list](https://github.com/absmach/magistrala-docs/issues) to determine if it already contains the
 problem that you are facing.
 
 A good bug report shouldn't leave others needing to chase you for more information. Please be as detailed as possible. The following questions might serve as a template for writing a detailed
@@ -43,7 +43,7 @@ clone your fork repository and configure the remotes:
 ```
 git clone https://github.com/<your-username>/docs.git
 cd docs
-git remote add upstream https://github.com/mainflux/docs.git
+git remote add upstream https://github.com/absmach/magistrala-docs.git
 ```
 
 If your cloned repository is behind the upstream commits, then get the latest changes from upstream:

diff --git a/README.md b/README.md
@@ -4,7 +4,6 @@
 [build][build]
 [![Build](https://github.com/absmach/magistrala-docs/actions/workflows/pages.yaml/badge.svg?branch=main)](https://github.com/absmach/magistrala-docs/actions/workflows/pages.yaml)
 
-
 This repo collects the collaborative work on Magistrala documentation.
 The official documentation is hosted at [Magistrala Docs page][docs].
 Documentation is auto-generated from Markdown files in this repo.

diff --git a/docs/api.md b/docs/api.md
@@ -8,7 +8,7 @@ API reference in the Swagger UI can be found at: [https://api.magistrala.abstrac
 
 ### Create User
 
-To start working with the Mainflux system, you need to create a user account.
+To start working with the Magistrala system, you need to create a user account.
 
 > Identity, which can be email-address (this must be unique as it identifies the user) and secret (password must contain at least 8 characters).
 
@@ -97,7 +97,7 @@ Access-Control-Expose-Headers: Location
 
 ### Create Token
 
-To log in to the Mainflux system, you need to create a `user_token`.
+To log in to the Magistrala system, you need to create a `user_token`.
 
 ```bash
 curl -sSiX POST http://localhost/users/tokens/issue -H "Content-Type: application/json" -d @- << EOF
@@ -682,9 +682,9 @@ Access-Control-Expose-Headers: Location
 
 ### Create Thing with External ID
 
-It is often the case that the user will want to integrate the existing solutions, e.g. an asset management system, with the Mainflux platform. To simplify the integration between the systems and avoid artificial cross-platform reference, such as special fields in Mainflux Things metadata, it is possible to set Mainflux Thing ID with an existing unique ID while create the Thing. This way, the user can set the existing ID as the Thing ID of a newly created Thing to keep reference between Thing and the asset that Thing represents.
+It is often the case that the user will want to integrate the existing solutions, e.g. an asset management system, with the Magistrala platform. To simplify the integration between the systems and avoid artificial cross-platform reference, such as special fields in Magistrala Things metadata, it is possible to set Magistrala Thing ID with an existing unique ID while create the Thing. This way, the user can set the existing ID as the Thing ID of a newly created Thing to keep reference between Thing and the asset that Thing represents.
 
-The limitation is that the existing ID has to be unique in the Mainflux domain.
+The limitation is that the existing ID has to be unique in the Magistrala domain.
 
 To create a thing with an external ID, you need to provide the ID together with thing name, and other fields as well as a `user_token`
 
@@ -720,8 +720,8 @@ Access-Control-Expose-Headers: Location
 
 ### Create Thing with External Secret
 
-It is often the case that the user will want to integrate the existing solutions, e.g. an asset management system, with the Mainflux platform. To simplify the integration between the systems and avoid artificial cross-platform reference, such as special fields in Mainflux Things metadata, it is possible to set Mainflux Thing secret with an existing unique secret when creating the Thing. This way, the user can set the existing secret as the Thing secret of a newly created Thing to keep reference between Thing and the asset that Thing represents.
-The limitation is that the existing secret has to be unique in the Mainflux domain.
+It is often the case that the user will want to integrate the existing solutions, e.g. an asset management system, with the Magistrala platform. To simplify the integration between the systems and avoid artificial cross-platform reference, such as special fields in Magistrala Things metadata, it is possible to set Magistrala Thing secret with an existing unique secret when creating the Thing. This way, the user can set the existing secret as the Thing secret of a newly created Thing to keep reference between Thing and the asset that Thing represents.
+The limitation is that the existing secret has to be unique in the Magistrala domain.
 
 To create a thing with an external secret, you need to provide the secret together with thing name, and other fields as well as a `user_token`
 
@@ -1357,7 +1357,7 @@ Access-Control-Expose-Headers: Location
 
 ### Create Channel with external ID
 
-Channel is a group of things that could represent a special category in existing systems, e.g. a building level channel could represent the level of a smarting building system. For helping to keep the reference, it is possible to set an existing ID while creating the Mainflux channel. There are two limitations - the existing ID has to be in UUID V4 format and it has to be unique in the Mainflux domain.
+Channel is a group of things that could represent a special category in existing systems, e.g. a building level channel could represent the level of a smarting building system. For helping to keep the reference, it is possible to set an existing ID while creating the Magistrala channel. There are two limitations - the existing ID has to be in UUID V4 format and it has to be unique in the Magistrala domain.
 
 To create a channel with external ID, the user needs to provide a UUID v4 format unique ID, and a `user_token`
 

diff --git a/docs/architecture.md b/docs/architecture.md
@@ -4,17 +4,17 @@
 
 Magistrala IoT platform is comprised of the following services:
 
-| Service                        | Description                                                                             |
-| :----------------------------- | :-------------------------------------------------------------------------------------- |
-| [users][users-service]         | Manages platform's users and auth concerns in regards to users and groups               |
-| [things][things-service]       | Manages platform's things, channels and auth concerns in regards to things and channels |
-| [http-adapter][http-adapter]   | Provides an HTTP interface for sending messages via HTTP                                |
-| [mqtt-adapter][mqtt-adapter]   | Provides an MQTT and MQTT over WS interface for sending and receiving messages via MQTT |
-| [ws-adapter][ws-adapter]       | Provides a WebSocket interface for sending and receiving messages via WS                |
-| [coap-adapter][coap-adapter]   | Provides a CoAP interface for sending and receiving messages via CoAP                   |
-| [opcua-adapter][opcua-adapter] | Provides an OPC-UA interface for sending and receiving messages via OPC-UA              |
-| [lora-adapter][lora-adapter]   | Provides a LoRa Server forwarder for sending and receiving messages via LoRa            |
-| [mainflux-cli][mainflux-cli]   | Command line interface                                                                  |
+| Service                          | Description                                                                             |
+| :------------------------------- | :-------------------------------------------------------------------------------------- |
+| [users][users-service]           | Manages platform's users and auth concerns in regards to users and groups               |
+| [things][things-service]         | Manages platform's things, channels and auth concerns in regards to things and channels |
+| [http-adapter][http-adapter]     | Provides an HTTP interface for sending messages via HTTP                                |
+| [mqtt-adapter][mqtt-adapter]     | Provides an MQTT and MQTT over WS interface for sending and receiving messages via MQTT |
+| [ws-adapter][ws-adapter]         | Provides a WebSocket interface for sending and receiving messages via WS                |
+| [coap-adapter][coap-adapter]     | Provides a CoAP interface for sending and receiving messages via CoAP                   |
+| [opcua-adapter][opcua-adapter]   | Provides an OPC-UA interface for sending and receiving messages via OPC-UA              |
+| [lora-adapter][lora-adapter]     | Provides a LoRa Server forwarder for sending and receiving messages via LoRa            |
+| [magistrala-cli][magistrala-cli] | Command line interface                                                                  |
 
 ![arch][architecture]
 
@@ -47,15 +47,15 @@ Magistrala platform can be run on the edge as well. Deploying Magistrala on a ga
 
 Running Magistrala on gateway moves computation from cloud towards the edge thus decentralizing IoT system. Since we can deploy same Magistrala code on gateway and in the cloud there are many benefits but the biggest one is easy deployment and adoption - once engineers understand how to deploy and maintain the platform, they will be able to apply those same skills to any part of the edge-fog-cloud continuum. This is because the platform is designed to be consistent, making it easy for engineers to move between them. This consistency will save engineers time and effort, and it will also help to improve the reliability and security of the platform. Same set of tools can be used, same patches and bug fixes can be applied. The whole system is much easier to reason about, and the maintenance is much easier and less costly.
 
-[users-service]: https://github.com/absmach/magistrala/terr/main/users
-[things-service]: https://github.com/absmach/magistrala/terr/main/things
-[http-adapter]: https://github.com/absmach/magistrala/terr/main/http
-[mqtt-adapter]: https://github.com/absmach/magistrala/terr/main/mqtt
-[coap-adapter]: https://github.com/absmach/magistrala/terr/main/coap
-[ws-adapter]: https://github.com/absmach/magistrala/terr/main/ws
-[opcua-adapter]: https://github.com/absmach/magistrala/terr/main/opcua
-[lora-adapter]: https://github.com/absmach/magistrala/terr/main/lora
-[mainflux-cli]: https://github.com/absmach/magistrala/terr/main/cli
+[users-service]: https://github.com/absmach/magistrala/tree/main/users
+[things-service]: https://github.com/absmach/magistrala/tree/main/things
+[http-adapter]: https://github.com/absmach/magistrala/tree/main/http
+[mqtt-adapter]: https://github.com/absmach/magistrala/tree/main/mqtt
+[coap-adapter]: https://github.com/absmach/magistrala/tree/main/coap
+[ws-adapter]: https://github.com/absmach/magistrala/tree/main/ws
+[opcua-adapter]: https://github.com/absmach/magistrala/tree/main/opcua
+[lora-adapter]: https://github.com/absmach/magistrala/tree/main/lora
+[magistrala-cli]: https://github.com/absmach/magistrala/tree/main/cli
 [architecture]: img/architecture.jpg
 [nats]: https://nats.io/
 [rabbitmq]: https://www.rabbitmq.com/

diff --git a/docs/authentication.md b/docs/authentication.md
@@ -32,13 +32,13 @@ MF_USERS_UI_REDIRECT_URL=http://localhost:9090
 2. `MF_USERS_GOOGLE_CLIENT_SECRET` - Google OAuth 2.0 client secret
 3. `MF_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. `MF_USERS_GOOGLE_STATE` - Random string used to protect against cross-site request forgery attacks.
-5. `MF_USERS_UI_REDIRECT_URL` - URL to redirect user after successful authentication. This can be your mainflux UI URL.
+5. `MF_USERS_UI_REDIRECT_URL` - URL to redirect user after successful authentication. This can be your Magistrala UI URL.
 
-Magistrala handles the authentication callback at `<MF_BASE_URL>/google-callback` endpoint, where `<MF_BASE_URL>` is the base URL of your Magistrala instance. This endpoint needs to be registered in the Google Cloud Platform and it must match the value of `MF_UI_GOOGLE_REDIRECT_URL` environment variable. From the UI, `google state` is prefixed with the `signin` or `signup` operation to be able to distinguish between sign-in and sign-up operations. For example, if a user is not signed up, the UI will display an error message and a button to sign-up. The error message is sent from the backend using a cookie with the name `error`. The UI will read the error message from the cookie and display it to the user. This cookie expires in 1 second. When a user signs up, mainflux 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 `MF_USERS_UI_REDIRECT_URL` environment variable upon successful authentication. This should be the base URL of your UI.
+Magistrala handles the authentication callback at `<MF_BASE_URL>/google-callback` endpoint, where `<MF_BASE_URL>` is the base URL of your Magistrala instance. This endpoint needs to be registered in the Google Cloud Platform and it must match the value of `MF_UI_GOOGLE_REDIRECT_URL` environment variable. From the UI, `google state` is prefixed with the `signin` or `signup` operation to be able to distinguish between sign-in and sign-up operations. For example, if a user is not signed up, the UI will display an error message and a button to sign-up. The error message is sent from the backend using a cookie with the name `error`. The UI will read the error message from the cookie and display it to the user. This cookie expires in 1 second. When a user signs up, Magistrala 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 `MF_USERS_UI_REDIRECT_URL` environment variable upon successful authentication. This should be the base URL of your UI.
 
 The `MF_USERS_GOOGLE_CLIENT_ID`, `MF_USERS_GOOGLE_CLIENT_SECRET`, `MF_UI_GOOGLE_REDIRECT_URL` and `MF_USERS_GOOGLE_STATE` environment variables should be the same for the UI and users service. The `MF_USERS_UI_REDIRECT_URL` environment variable should be the URL of your UI which is used to redirect the user after successful authentication.
 
-Magistrala 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 mainflux 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.
+Magistrala 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 Magistrala 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.
 
 ## Authentication with Magistrala keys
 
@@ -71,8 +71,8 @@ These commands use [OpenSSL][openssl] tool, so please make sure that you have it
 CRT_LOCATION = certs
 THING_SECRET = d7cc2964-a48b-4a6e-871a-08da28e7883d
 O = Magistrala
-OU = mainflux
-EA = info@mainflux.com
+OU = magistrala
+EA = info@magistrala.com
 CN = localhost
 CRT_FILE_NAME = thing
 ```

diff --git a/docs/benchmark.md b/docs/benchmark.md
@@ -135,6 +135,6 @@ TBD
 [satori]: https://github.com/satori-com/mzbench
 [mzbench-cli]: https://github.com/mzbench/mzbench/blob/master/doc/cli.md
 [mzbench-dashboard]: https://github.com/mzbench/mzbench/blob/master/doc/dashboard.md
-[mf-benchmark]: https://github.com/mainflux/benchmark/terr/main/mzbench
+[mf-benchmark]: https://github.com/mainflux/benchmark/tree/master/mzbench
 [mzbench-architecture-running]: https://github.com/mzbench/mzbench/raw/master/doc/images/scheme_2.png
 [mzbench-scenarios]: https://github.com/mzbench/mzbench/blob/master/scenarios/spec.md#pre_hook-and-post_hook