lingwei.kong/hawkbit
1
0
Fork 0
Code Issues Pull Requests Actions 3 Packages Projects Releases Wiki Activity

Code format hawkbit (#1948)

Browse Source 
Signed-off-by: Marinov Avgustin <Avgustin.Marinov@bosch.com>
This commit is contained in:
Avgustin Marinov
2024-11-05 11:41:56 +02:00
committed by GitHub
parent 3e469fa58c
commit d842bc2aaa
108 changed files with 17957 additions and 12571 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
site/content/apis/ddi_api.md
View File

@@ -4,32 +4,39 @@ parent: APIs
weight: 82
---
The hawkBit [update server](https://github.com/eclipse-hawkbit/hawkbit) provides REST resources which are consumed by the device to retrieve software update tasks.
The hawkBit [update server](https://github.com/eclipse-hawkbit/hawkbit) provides REST resources which are consumed by
the device to retrieve software update tasks.
This API is based on HTTP standards and a polling mechanism.
<!--more-->
{{% note %}}
In DDI the target is identified using a **controllerId**. Controller is used as a term for the actual service/client on the device. That allows users to have in some cases even multiple clients on the same target for different tasks, e.g. Firmware update and App management.
In DDI the target is identified using a **controllerId**. Controller is used as a term for the actual service/client on
the device. That allows users to have in some cases even multiple clients on the same target for different tasks, e.g.
Firmware update and App management.
{{% /note %}}
## State Machine Mapping
For historical reasons the DDI has a different state machine and status messages than the [Target State Machine](../../concepts/targetstate/) of the hawkBit update server.
For historical reasons the DDI has a different state machine and status messages than
the [Target State Machine](../../concepts/targetstate/) of the hawkBit update server.
This is kept in order to ensure that _DDI_ stays compatible for devices out there in the field. A future version "2" of _DDI_ might change that. _DDI_ also defines more states than the update server, e.g. multiple DDI states are currently mapped by the _DDI_ implementation to _RUNNING_ state. It is possible that in the future hawkBit will fully leverage these additional states.
This is kept in order to ensure that _DDI_ stays compatible for devices out there in the field. A future version "2" of
_DDI_ might change that. _DDI_ also defines more states than the update server, e.g. multiple DDI states are currently
mapped by the _DDI_ implementation to _RUNNING_ state. It is possible that in the future hawkBit will fully leverage
these additional states.
The _DDI_ API allows the device to provide the following feedback messages:
DDI `status.execution` type | handling by update server | Mapped ActionStatus type
--------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -----------------------------------------------------
CANCELED | This is send by the target as confirmation of a cancellation request by the update server. | CANCELED
REJECTED | This is send by the target in case an update of a cancellation is rejected, i.e. cannot be fulfilled at this point in time. Note: the target should send a CLOSED->ERROR if it believes it will not be able to proceed the action at all. | WARNING
CLOSED | Target completes the action either with `status.result.finished` SUCCESS or FAILURE as result. Note: DDI defines also a status NONE which will not be interpreted by the update server and handled like SUCCESS. | ERROR (DDI FAILURE) or FINISHED (DDI SUCCESS or NONE)
DOWNLOAD | This can be used by the target to inform that it is downloading artifacts of the action. | DOWNLOAD
DOWNLOADED | This can be used by the target to inform that it has downloaded artifacts of the action. | DOWNLOADED
PROCEEDING | This can be used by the target to inform that it is working on the action. | RUNNING
SCHEDULED | This can be used by the target to inform that it scheduled on the action. | RUNNING
RESUMED | This can be used by the target to inform that it continued to work on the action. | RUNNING
DDI `status.execution` type | handling by update server | Mapped ActionStatus type
-----------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------
CANCELED | This is send by the target as confirmation of a cancellation request by the update server. | CANCELED
REJECTED | This is send by the target in case an update of a cancellation is rejected, i.e. cannot be fulfilled at this point in time. Note: the target should send a CLOSED->ERROR if it believes it will not be able to proceed the action at all. | WARNING
CLOSED | Target completes the action either with `status.result.finished` SUCCESS or FAILURE as result. Note: DDI defines also a status NONE which will not be interpreted by the update server and handled like SUCCESS. | ERROR (DDI FAILURE) or FINISHED (DDI SUCCESS or NONE)
DOWNLOAD | This can be used by the target to inform that it is downloading artifacts of the action. | DOWNLOAD
DOWNLOADED | This can be used by the target to inform that it has downloaded artifacts of the action. | DOWNLOADED
PROCEEDING | This can be used by the target to inform that it is working on the action. | RUNNING
SCHEDULED | This can be used by the target to inform that it scheduled on the action. | RUNNING
RESUMED | This can be used by the target to inform that it continued to work on the action. | RUNNING
## DDI APIs

72
site/content/apis/dmf_api.md
View File

@@ -4,7 +4,8 @@ parent: API
weight: 83
---
The DMF API provides Java classes which allows that the message body can be deserialized at runtime into a Java object. Also Java classes can be used to serialize Java objects into JSON bodies to send a message to hawkBit.
The DMF API provides Java classes which allows that the message body can be deserialized at runtime into a Java object.
Also Java classes can be used to serialize Java objects into JSON bodies to send a message to hawkBit.
Currently, bodies of messages are based on JSON.
<!--more-->
@@ -22,20 +23,22 @@ Bindings determine how messages get put in this place
Queues can also be bound to multiple exchanges.
**Exchanges** are just publish messages.
The user decides who can produce on an exchange and who can create bindings on that exchange for delivery to a specific queue.
The user decides who can produce on an exchange and who can create bindings on that exchange for delivery to a specific
queue.
hawkBit will create all necessary queues, exchanges and bindings for the user, making it easy to get started.
The exchange name for outgoing messages is **dmf.exchange**.
The user has to set a `reply_to` header (see chapter below), in order to specify the exchange to which hawkBit should reply to.
The user has to set a `reply_to` header (see chapter below), in order to specify the exchange to which hawkBit should
reply to.
The following chapter describes the message body, header and properties.
Note: the DMF protocol was intended to be compatible to other use cases by design. As a result, DMF uses the term **thing** and not **target** but they are actually synonyms in this case.
Note: the DMF protocol was intended to be compatible to other use cases by design. As a result, DMF uses the term *
*thing** and not **target** but they are actually synonyms in this case.
## Messages sent to hawkBit (Client -> hawkBit)
### THING_CREATED
Message to register and update a provisioning target.
@@ -76,9 +79,10 @@ Payload Template (optional):
The "name" property specifies the name of the thing, which by default is the thing ID. This property is optional.<br />
<br />
The "type" property specifies name of a target type which should be assigned to the created/updated target. The
The "type" property specifies name of a target type which should be assigned to the created/updated target. The
target type with the specified name should be created in advance, otherwise it can't be assigned to the target,
resulting in:
* error is logged
* if the target does not exist then it is created without any target type assigned
* if it exists already then no changes to its target type assignment are made.
@@ -87,8 +91,8 @@ If the "type" property is set to a blank string while updating an existing targe
assignment is removed from the target. This property is optional and if omitted then no changes to the target type
assignment are made.<br />
<br />
The "attributeUpdate" property provides the attributes of the thing, for details see UPDATE_ATTRIBUTES message. This property is optional.
The "attributeUpdate" property provides the attributes of the thing, for details see UPDATE_ATTRIBUTES message. This
property is optional.
### THING_REMOVED
@@ -112,7 +116,8 @@ Example headers
### UPDATE_ATTRIBUTES
Message to update target attributes. This message can be send in response to a REQUEST_ATTRIBUTES_UPDATE event, sent by hawkBit.
Message to update target attributes. This message can be send in response to a REQUEST_ATTRIBUTES_UPDATE event, sent by
hawkBit.
| Header | Description | Type | Mandatory |
|---------|----------------------------------|----------------------------------|-----------|
@@ -121,9 +126,9 @@ Message to update target attributes. This message can be send in response to a R
| thingId | The ID of the registered thing | String | true |
| tenant | The tenant this thing belongs to | String | false |
| Message Properties | Description | Type | Mandatory |
|-----------------------------|----------------------------------|--------|-----------|
| content_type | The content type of the payload | String | true |
| Message Properties | Description | Type | Mandatory |
|--------------------|---------------------------------|--------|-----------|
| content_type | The content type of the payload | String | true |
Example header and payload:
@@ -143,7 +148,9 @@ Payload Template:
}
```
The "mode" property specifies the update mode that should be applied. This property is optional. Possible [mode](https://github.com/eclipse-hawkbit/hawkbit/tree/master/hawkbit-dmf/hawkbit-dmf-api/src/main/java/org/eclipse/hawkbit/dmf/json/model/DmfUpdateMode.java) values:
The "mode" property specifies the update mode that should be applied. This property is optional.
Possible [mode](https://github.com/eclipse-hawkbit/hawkbit/tree/master/hawkbit-dmf/hawkbit-dmf-api/src/main/java/org/eclipse/hawkbit/dmf/json/model/DmfUpdateMode.java)
values:
| Value | Description |
|---------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
@@ -165,7 +172,8 @@ Message to send an action status event to hawkBit.
|--------------------|---------------------------------|--------|-----------|
| content_type | The content type of the payload | String | true |
Payload Template (the Java representation is [ActionUpdateStatus](https://github.com/eclipse-hawkbit/hawkbit/tree/master/hawkbit-dmf/hawkbit-dmf-api/src/main/java/org/eclipse/hawkbit/dmf/json/model/DmfActionUpdateStatus.java)):
Payload Template (the Java representation
is [ActionUpdateStatus](https://github.com/eclipse-hawkbit/hawkbit/tree/master/hawkbit-dmf/hawkbit-dmf-api/src/main/java/org/eclipse/hawkbit/dmf/json/model/DmfActionUpdateStatus.java)):
```json
{
@@ -176,7 +184,8 @@ Payload Template (the Java representation is [ActionUpdateStatus](https://github
}
```
Possible [actionStatus](https://github.com/eclipse-hawkbit/hawkbit/tree/master/hawkbit-dmf/hawkbit-dmf-api/src/main/java/org/eclipse/hawkbit/dmf/json/model/DmfActionStatus.java) values:
Possible [actionStatus](https://github.com/eclipse-hawkbit/hawkbit/tree/master/hawkbit-dmf/hawkbit-dmf-api/src/main/java/org/eclipse/hawkbit/dmf/json/model/DmfActionStatus.java)
values:
| Value | Description |
|-----------------|-----------------------------------------|
@@ -207,7 +216,8 @@ Example header and payload:
### PING
hawkBit allows DMF clients to check the availability of the DMF service. For this scenario DMF specifies a PING message that can be sent by the client:
hawkBit allows DMF clients to check the availability of the DMF service. For this scenario DMF specifies a PING message
that can be sent by the client:
| Header | Description | Type | Mandatory |
|--------|--------------------------------|---------------------|-----------|
@@ -255,7 +265,8 @@ Example Headers and Payload:
}
```
After sending this message, an action status event with either actionStatus=CANCELED or actionStatus=CANCEL_REJECTED has to be returned.
After sending this message, an action status event with either actionStatus=CANCELED or actionStatus=CANCEL_REJECTED has
to be returned.
Example header and payload when cancellation is successful:
@@ -287,10 +298,10 @@ Example header and payload when cancellation is rejected:
}
```
### DOWNLOAD_AND_INSTALL or DOWNLOAD
Message sent by hawkBit to initialize an update or download task. Note: in case of a maintenance window configured but not yet active the message will have the topic _DOWNLOAD_ instead of _DOWNLOAD_AND_INSTALL_.
Message sent by hawkBit to initialize an update or download task. Note: in case of a maintenance window configured but
not yet active the message will have the topic _DOWNLOAD_ instead of _DOWNLOAD_AND_INSTALL_.
| Header | Description | Type | Mandatory |
|---------|------------------------------------------------|---------------------------------------------------|-----------|
@@ -303,7 +314,8 @@ Message sent by hawkBit to initialize an update or download task. Note: in case
|--------------------|---------------------------------|--------|-----------|
| content_type | The content type of the payload | String | true |
Payload Template (the Java representation is [DmfDownloadAndUpdateRequest](https://github.com/eclipse-hawkbit/hawkbit/tree/master/hawkbit-dmf/hawkbit-dmf-api/src/main/java/org/eclipse/hawkbit/dmf/json/model/DmfDownloadAndUpdateRequest.java)):
Payload Template (the Java representation
is [DmfDownloadAndUpdateRequest](https://github.com/eclipse-hawkbit/hawkbit/tree/master/hawkbit-dmf/hawkbit-dmf-api/src/main/java/org/eclipse/hawkbit/dmf/json/model/DmfDownloadAndUpdateRequest.java)):
```json
{
@@ -375,13 +387,13 @@ Example header and payload:
}
```
### MULTI_ACTION
If `multi.assignments.enabled` is enabled, this message is sent instead of DOWNLOAD_AND_INSTALL, DOWNLOAD, or CANCEL_DOWNLOAD
by hawkBit to initialize update, download, or cancel task(s).
If `multi.assignments.enabled` is enabled, this message is sent instead of DOWNLOAD_AND_INSTALL, DOWNLOAD, or
CANCEL_DOWNLOAD
by hawkBit to initialize update, download, or cancel task(s).
With weight, one can set the priority to the action. The higher the weight, the higher is the priority of an action.
With weight, one can set the priority to the action. The higher the weight, the higher is the priority of an action.
| Header | Description | Type | Mandatory |
|---------|------------------------------------------------|-----------------------------|-----------|
@@ -394,7 +406,8 @@ If `multi.assignments.enabled` is enabled, this message is sent instead of DOWNL
|--------------------|---------------------------------|--------|-----------|
| content_type | The content type of the payload | String | true |
Payload Template (the Java representation is [DmfMultiActionRequest](https://github.com/eclipse-hawkbit/hawkbit/tree/master/hawkbit-dmf/hawkbit-dmf-api/src/main/java/org/eclipse/hawkbit/dmf/json/model/DmfMultiActionRequest.java)):
Payload Template (the Java representation
is [DmfMultiActionRequest](https://github.com/eclipse-hawkbit/hawkbit/tree/master/hawkbit-dmf/hawkbit-dmf-api/src/main/java/org/eclipse/hawkbit/dmf/json/model/DmfMultiActionRequest.java)):
```json
[{
@@ -540,7 +553,6 @@ Example header and payload:
}]
```
### THING_DELETED
Message sent by hawkBit when a target has been deleted.
@@ -557,7 +569,6 @@ Example header:
|--------------------------------------------------------------|-------------------|
| type=THING\_DELETED <br /> tenant=default <br /> thingId=abc | |
### REQUEST_ATTRIBUTES_UPDATE
Message sent by Eclipse hawkBit when a re-transmission of target attributes is requested.
@@ -575,10 +586,10 @@ Example headers:
|----------------------------------------------------------------------------------------------|-------------------|
| type=EVENT <br /> tenant=default <br /> thingId=abc <br /> topic=REQUEST\_ATTRIBUTES\_UPDATE | |
### PING_RESPONSE
_hawkBit_ will respond to the PING message with a PING_RESPONSE type message that has the same correlationId as the original PING message:
_hawkBit_ will respond to the PING message with a PING_RESPONSE type message that has the same correlationId as the
original PING message:
| Header | Description | Type | Mandatory |
|--------|--------------------------------|------------------------------|-----------|
@@ -590,7 +601,8 @@ _hawkBit_ will respond to the PING message with a PING_RESPONSE type message tha
| correlationId | CorrelationId of the original PING request | String | true |
| content_type | The content type of the payload | String | true |
The PING_RESPONSE also contains a timestamp (i.e. the difference, measured in milliseconds, between the current time and midnight, January 1, 1970 UTC) as plain text. It is not guaranteed that this timestamp is completely accurate.
The PING_RESPONSE also contains a timestamp (i.e. the difference, measured in milliseconds, between the current time and
midnight, January 1, 1970 UTC) as plain text. It is not guaranteed that this timestamp is completely accurate.
| Header | MessageProperties |
|-------------------------------------------|-------------------------|

18
site/content/apis/management_api.md
View File

@@ -4,16 +4,20 @@ parent: API
weight: 81
---
The Management API is a RESTful API that enables to perform Create/Read/Update/Delete operations for provisioning targets (i.e. devices) and repository content (i.e. software).
The Management API is a RESTful API that enables to perform Create/Read/Update/Delete operations for provisioning
targets (i.e. devices) and repository content (i.e. software).
<!--more-->
Based on the Management API you can manage and monitor software update operations via HTTP/HTTPS. The _Management API_ supports JSON payload with hypermedia as well as filtering, sorting and paging. Furthermore the Management API provides permission based access control and standard roles as well as custom role creation.
Based on the Management API you can manage and monitor software update operations via HTTP/HTTPS. The _Management API_
supports JSON payload with hypermedia as well as filtering, sorting and paging. Furthermore the Management API provides
permission based access control and standard roles as well as custom role creation.
The API is protected and needs authentication and authorization based on the security concept.
## API Version
hawkBit provides an consistent Management API interface that guarantees backwards compatibility for future releases by version control.
hawkBit provides an consistent Management API interface that guarantees backwards compatibility for future releases by
version control.
The current version of the Management API is `version 1 (v1)` with the URI http://localhost:8080/rest/v1/
@@ -42,10 +46,11 @@ In addition, for POST and PUT requests the `Content-Type` header has to be set.
## Request Body
Besides the relevant data (name, description, createdBy etc.) of a resource entity, a resource entity also has URIs (`_links`) to linked resource entities.
A _Distribution Set_ entity may have for example URIs to artifacts, _Software Modules_, _Software Module Types_ and metadata.
Besides the relevant data (name, description, createdBy etc.) of a resource entity, a resource entity also has
URIs (`_links`) to linked resource entities.
A _Distribution Set_ entity may have for example URIs to artifacts, _Software Modules_, _Software Module Types_ and
metadata.
```json
"_links": {
@@ -65,5 +70,4 @@ A _Distribution Set_ entity may have for example URIs to artifacts, _Software Mo
## Management APIs
<iframe style="padding-top: 20px;" width="100%" height="900px" frameborder="0" src="../../rest-api/mgmt.html"></iframe>

92
site/content/blog/2018-07-26-first-release.md
View File

@@ -4,17 +4,19 @@ parent: Blog
weight: 200
---
hawkBit is a domain-independent back-end framework for rolling out software updates to constrained edge devices as well
as more powerful controllers and gateways connected to IP based networking infrastructure. It is part of the Eclipse IoT
hawkBit is a domain-independent back-end framework for rolling out software updates to constrained edge devices as well
as more powerful controllers and gateways connected to IP based networking infrastructure. It is part of the Eclipse IoT
since 2015 and with version _0.2.0_ a first release is available.
In this article, we want to give an overview of the latest highlights of hawkBit and let you know how you can get
In this article, we want to give an overview of the latest highlights of hawkBit and let you know how you can get
started in seconds.
## Finally, it is here!
## Finally, it is here!
After being around in the Eclipse IoT realm for quite some time now, we are more than happy to announce our first release:
[_Eclipse hawkBit 0.2.0_](https://projects.eclipse.org/projects/iot.hawkbit/releases/0.2.0). The release can be found on [Maven Central](https://mvnrepository.com/artifact/org.eclipse.hawkbit)
After being around in the Eclipse IoT realm for quite some time now, we are more than happy to announce our first
release:
[_Eclipse hawkBit 0.2.0_](https://projects.eclipse.org/projects/iot.hawkbit/releases/0.2.0). The release can be found
on [Maven Central](https://mvnrepository.com/artifact/org.eclipse.hawkbit)
and [Docker Hub](https://hub.docker.com/r/hawkbit/hawkbit-update-server/). It includes the following core features:
* Device and Software Repository
@@ -31,63 +33,69 @@ The features are accessible via the following interfaces:
![hawkBit Overview](../../images/hawkBit_overview.jpeg)
## What's new?
Whenever there is a new release, the first question that comes to mind is: What's new? Since this is our first release,
one could argue that everything is new. However, most of the features are already well-established. This holds true, for
example, for our APIs or the Rollout Management. Nevertheless, there have been some recent updates to hawkBit, which we
do not want to leave unmentioned:
Whenever there is a new release, the first question that comes to mind is: What's new? Since this is our first release,
one could argue that everything is new. However, most of the features are already well-established. This holds true, for
example, for our APIs or the Rollout Management. Nevertheless, there have been some recent updates to hawkBit, which we
do not want to leave unmentioned:
### Streamlined UI
The probably most noticeable change has been the removal of the two buttons (`Drop here to delete` and `Actions`) at the
bottom of the _Deployment_, _Distributions_, and _Upload_ view. This is a major usability improvement! For example,
deleting an item required (1) dragging an item onto the delete button, (2) opening the delete pop-up, and (3) confirming
the deletion. Now, an item can be easily removed by clicking on its remove icon and confirming the action. Moreover,
multiple (or all `CTRL` + `A`) items can be selected and removed at once using the same mechanism. This is not only
faster and more intuitive, it also saves a lot of display real estate which can now be used to focus on what is important.
The probably most noticeable change has been the removal of the two buttons (`Drop here to delete` and `Actions`) at the
bottom of the _Deployment_, _Distributions_, and _Upload_ view. This is a major usability improvement! For example,
deleting an item required (1) dragging an item onto the delete button, (2) opening the delete pop-up, and (3) confirming
the deletion. Now, an item can be easily removed by clicking on its remove icon and confirming the action. Moreover,
multiple (or all `CTRL` + `A`) items can be selected and removed at once using the same mechanism. This is not only
faster and more intuitive, it also saves a lot of display real estate which can now be used to focus on what is
important.
We hope you like this change as much as we do! _(Requires: hawkBit > 0.2.2)_
![Screenshot of improved UI](../../images/hawkbit_ui.png)
### MS SQL Server
Eclipse hawkBit supports a range of different SQL databases. Up to now, these have been the internal H2 database (which can be
used for testing, development, or trial) and MySQL/MariaDB for production-grade usage. This list is now extended by
Eclipse hawkBit supports a range of different SQL databases. Up to now, these have been the internal H2 database (which
can be
used for testing, development, or trial) and MySQL/MariaDB for production-grade usage. This list is now extended by
Microsoft's SQL Server which is also available in production grade, as well as, IBM's DB2 for testing and development.
### Open Sourced REST docs
A huge benefit for the community is the recently open sourced REST docs of hawkBit. This has been an [open request](https://github.com/eclipse-hawkbit/hawkbit/issues/480)
for some time, which we were happy to meet. The documentation is generated using [Spring REST docs](https://spring.io/projects/spring-restdocs), based on unit-tests. These tests, with the respective documentation, are now available in the [code base](https://github.com/eclipse-hawkbit/hawkbit/pull/688).
Furthermore, the API documentation will be hosted on our new [website](https://www.eclipse.org/hawkbit/) (coming soon).
A huge benefit for the community is the recently open sourced REST docs of hawkBit. This has been
an [open request](https://github.com/eclipse-hawkbit/hawkbit/issues/480)
for some time, which we were happy to meet. The documentation is generated
using [Spring REST docs](https://spring.io/projects/spring-restdocs), based on unit-tests. These tests, with the
respective documentation, are now available in the [code base](https://github.com/eclipse-hawkbit/hawkbit/pull/688).
Furthermore, the API documentation will be hosted on our new [website](https://www.eclipse.org/hawkbit/) (coming soon).
### Docker Images
In order to enable interested parties to get started with hawkBit conveniently, we decided to provide the
[Update Server as a Docker image](https://hub.docker.com/r/hawkbit/hawkbit-update-server/) on Docker Hub. The image comes
in two flavors: The default image uses the internal H2 database, while the images with a `-mysql` suffix contain the MySQL
driver to allow connecting a MySQL database. In addition to the Docker image, the hawkBit repository contains a
[docker-compose.yml](https://github.com/eclipse-hawkbit/hawkbit/blob/master/hawkbit-runtime/hawkbit-update-server/docker/docker-compose.yml)
that not only starts the Update Server, but further includes a MySQL database and a RabbitMQ message broker so you're
able to use Device Management Federation (DMF) as well.
In order to enable interested parties to get started with hawkBit conveniently, we decided to provide the
[Update Server as a Docker image](https://hub.docker.com/r/hawkbit/hawkbit-update-server/) on Docker Hub. The image
comes
in two flavors: The default image uses the internal H2 database, while the images with a `-mysql` suffix contain the
MySQL
driver to allow connecting a MySQL database. In addition to the Docker image, the hawkBit repository contains a
[docker-compose.yml](https://github.com/eclipse-hawkbit/hawkbit/blob/master/hawkbit-runtime/hawkbit-update-server/docker/docker-compose.yml)
that not only starts the Update Server, but further includes a MySQL database and a RabbitMQ message broker so you're
able to use Device Management Federation (DMF) as well.
To start the hawkBit Update Server image, open a terminal and run:
To start the hawkBit Update Server image, open a terminal and run:
```
$ docker run -d -p 8080:8080 hawkbit/hawkbit-update-server
```
{{% note %}}
_Note: This requires a running [Docker deamon](https://docs.docker.com/install/) on your system._
{{% /note %}}
Now, browse to [http://localhost:8080](http://localhost:8080) and log-in with `admin:admin`. There you go!
Now, browse to [http://localhost:8080](http://localhost:8080) and log-in with `admin:admin`. There you go!
## Community Updates
Although features and functionality play a major role in the hawkBit project, there is also some interesting news from
Although features and functionality play a major role in the hawkBit project, there is also some interesting news from
the community. As of July 2018, there have been:
* Pull Requests: 587
@@ -98,17 +106,19 @@ the community. As of July 2018, there have been:
### New Project Lead and Committers
We are happy to announce that the hawkBit project got a new project lead. In addition to
[Kai Zimmermann](https://projects.eclipse.org/user/6364), project lead from the first hour,
[Jeroen Laverman](https://projects.eclipse.org/user/10982) joined the lead to support him in this responsibility.
Moreover, with [Stefan Behl](https://projects.eclipse.org/user/10842) and Jeroen Laverman, two new committers are aboard.
We are happy to announce that the hawkBit project got a new project lead. In addition to
[Kai Zimmermann](https://projects.eclipse.org/user/6364), project lead from the first hour,
[Jeroen Laverman](https://projects.eclipse.org/user/10982) joined the lead to support him in this responsibility.
Moreover, with [Stefan Behl](https://projects.eclipse.org/user/10842) and Jeroen Laverman, two new committers are
aboard.
## What's next?
Looking ahead, there are two major topics that we want to tackle next: First, there is the migration of our UI from Vaadin
Looking ahead, there are two major topics that we want to tackle next: First, there is the migration of our UI from
Vaadin
7 to Vaadin 8, since Vaadin announced the end-of-life for our current version. Another big topic will be the update
to Spring Boot 2. On the community side, we are in the final stage of updating our [website](https://www.eclipse.org/hawkbit/)
with a new design, so make sure you stop by in a couple of days to check it out. Finally, the hawkBit team will be
to Spring Boot 2. On the community side, we are in the final stage of updating
our [website](https://www.eclipse.org/hawkbit/)
with a new design, so make sure you stop by in a couple of days to check it out. Finally, the hawkBit team will be
present at EclipseCon Europe 2018, so if you are interested in meeting us, that is the place to be.

3
site/content/blog/2023-09-21-epl2.0.md
View File

@@ -15,6 +15,7 @@ In this article, we want to give an overview of the latest highlights of hawkBit
Based on the issues
[Switch to EPL 2.0 License](https://github.com/eclipse-hawkbit/hawkbit/issues/1393) and
[Update hawkBit's license to EPL 2.0](https://github.com/eclipse-hawkbit/hawkbit/issues/1008)
the hawkBit license is upgraded from [Eclipse Public License - Version 1.0](http://www.eclipse.org/org/documents/epl-v10.php) to
the hawkBit license is upgraded
from [Eclipse Public License - Version 1.0](http://www.eclipse.org/org/documents/epl-v10.php) to
[Eclipse Public License - v 2.0](https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.txt).

30
site/content/blog/2023-11-22-vaadin8_ui_discontinuation.md
View File

@@ -8,18 +8,34 @@ In this article, we want to give an overview of the future of the hawkBit UI
## hawkBit Vaadin 8 UI discontinuation
The hawkBit UI uses Vaadin as a web UI framework. It uses Vaadin 8 (8.14.3). This major version, according [Vaadin Roadmap](https://vaadin.com/roadmap), has no free support since 21st Feb 2022. There are some version releases after that date (8.15.0 - 8.16.0) that are Apache 2.0 licensed. However, since 8.16.1 ([see here](https://mvnrepository.com/artifact/com.vaadin/vaadin-server)) the license is [Commercial Vaadin Developer License 4.0](https://vaadin.com/license/cvdl-4.0), so they could not be used in hawkBit.
The hawkBit UI uses Vaadin as a web UI framework. It uses Vaadin 8 (8.14.3). This major version,
according [Vaadin Roadmap](https://vaadin.com/roadmap), has no free support since 21st Feb 2022. There are some version
releases after that date (8.15.0 - 8.16.0) that are Apache 2.0 licensed. However, since
8.16.1 ([see here](https://mvnrepository.com/artifact/com.vaadin/vaadin-server)) the license
is [Commercial Vaadin Developer License 4.0](https://vaadin.com/license/cvdl-4.0), so they could not be used in hawkBit.
We believe it is not a good practice to keep an out of free support library in an open source project like hawkBit. And moreover, even if we keep it, if a security vulnerability is discovered - all users shall opt for commercial support or to drop UI.
We believe it is not a good practice to keep an out of free support library in an open source project like hawkBit. And
moreover, even if we keep it, if a security vulnerability is discovered - all users shall opt for commercial support or
to drop UI.
There is another critical obstacle with keeping Vaadin 8 UI. At the moment hawkBit uses Spring Boot 2.7. According to [Spring Boot EOL](https://endoflife.date/spring-boot) Spring Boot 2.7 stream will reach end of support 24th Nov 2023. So, hawkBit shall be migrated to Spring Boot 3.0+. Since Vaadin 8 seem to be incompatible with Spring Boot 3 (they added support for Spring Boot 3 in Vaadin 24 ([Vaadin 24 pre release](https://vaadin.com/blog/vaadin-24-pre-release-available-for-spring-boot-3.0)) we shall drop Vaadin UI 8 anyway.
There is another critical obstacle with keeping Vaadin 8 UI. At the moment hawkBit uses Spring Boot 2.7. According
to [Spring Boot EOL](https://endoflife.date/spring-boot) Spring Boot 2.7 stream will reach end of support 24th Nov 2023.
So, hawkBit shall be migrated to Spring Boot 3.0+. Since Vaadin 8 seem to be incompatible with Spring Boot 3 (they added
support for Spring Boot 3 in Vaadin
24 ([Vaadin 24 pre release](https://vaadin.com/blog/vaadin-24-pre-release-available-for-spring-boot-3.0)) we shall drop
Vaadin UI 8 anyway.
Many months ago we asked for community help to migrate hawkBit UI to newer Vaadin versions - [Urgent migration needed to a newer Vaadin version
](https://github.com/eclipse-hawkbit/hawkbit/issues/1376) and gitter channel. However, there was no volunteer found to do the migration.
Many months ago we asked for community help to migrate hawkBit UI to newer Vaadin
versions - [Urgent migration needed to a newer Vaadin version
](https://github.com/eclipse-hawkbit/hawkbit/issues/1376) and gitter channel. However, there was no volunteer found to
do the migration.
All this being said, unfortunately, we've come to the decision to drop the Vaadin 8 UI from the Eclipse hawkBit and the latest hawkBit release 0.3.0 is the last version of hawkBit that includes it. For the next 0.4.0 release we plan to remove this Vaadin 8 UI. Thus the hawkBit may become an UI-less project.
All this being said, unfortunately, we've come to the decision to drop the Vaadin 8 UI from the Eclipse hawkBit and the
latest hawkBit release 0.3.0 is the last version of hawkBit that includes it. For the next 0.4.0 release we plan to
remove this Vaadin 8 UI. Thus the hawkBit may become an UI-less project.
There were steps taken to mitigate the problem:
There were steps taken to mitigate the problem:
* extending the REST API
* introducing Swagger UI which allow easier use of the REST API

39
site/content/blog/2024-01-16-0.4.1-release.md
View File

@@ -9,19 +9,42 @@ In this article, we want to give an overview of the 0.4.1 hawkBit release (Frida
## hawkBit [0.4.1](https://github.com/eclipse-hawkbit/hawkbit/releases/tag/0.4.1) release
### Steps towards removal of the legacy Vaadin8-based UI
As announced at [Vaadin 8 UI discontinuation](2023-11-22-vaadin8_ui_discontinuation.md) the current Vaadin 8 based UI will be removed. This release will likely be the last one including it. Some steps are taken to mitigate this.
* First of all, this release introduces [Simple UI](https://github.com/eclipse-hawkbit/hawkbit/tree/0.4.1/hawkbit-runtime/hawkbit-simple-ui) - a demo/PoC level UI. It includes the most essential functionality allowing you to play around with hawkBit. It could not be compared to legacy UI in features and maturity in any case. Some notes for it:
As announced at [Vaadin 8 UI discontinuation](2023-11-22-vaadin8_ui_discontinuation.md) the current Vaadin 8 based UI
will be removed. This release will likely be the last one including it. Some steps are taken to mitigate this.
* First of all, this release
introduces [Simple UI](https://github.com/eclipse-hawkbit/hawkbit/tree/0.4.1/hawkbit-runtime/hawkbit-simple-ui) - a
demo/PoC level UI. It includes the most essential functionality allowing you to play around with hawkBit. It could not
be compared to legacy UI in features and maturity in any case. Some notes for it:
* *Status* - as already said - low maturity and very feature-limited, *EXPERIMENTAL*
* Intended for demo/play-around purposes. It could become an initial version of a new hawkBit UI but currently, there are no resources for further development. Any contribution to this UI in the direction of making it a full-fledged mature UI is welcome!
* Intended for demo/play-around purposes. It could become an initial version of a new hawkBit UI but currently,
there are no resources for further development. Any contribution to this UI in the direction of making it a
full-fledged mature UI is welcome!
* It provides features like - create software modules & distribution sets, targets, and rollouts
* In contrast with legacy UI the new UI is a standalone application and uses only REST API to provide functionality to the user.
* To the legacy monolith update server application there is added a new microservice-based application. As part of this effort, there was introduced an example of [legacy Vaadin 8 UI standalone application](https://github.com/eclipse-hawkbit/hawkbit/tree/0.4.1/hawkbit-runtime/hawkbit-vv8-ui). This legacy UI standalone application could be used together with future hawkBit update server versions as long as it is compatible and on the user's responsibility. Some notes for it:
* *NOT RECOMMENDED* - it might contain security vulnerabilities and bugs. It could be hard to verify its compatibility with the new hawkBit versions.
* *ON USER's RESPONSIBILITY* - no guarantees of any kind are provided for that application. It is entirely the user's responsibility to test, scan for vulnerabilities, and use it.
* In contrast with legacy UI the new UI is a standalone application and uses only REST API to provide functionality
to the user.
* To the legacy monolith update server application there is added a new microservice-based application. As part of this
effort, there was introduced an example
of [legacy Vaadin 8 UI standalone application](https://github.com/eclipse-hawkbit/hawkbit/tree/0.4.1/hawkbit-runtime/hawkbit-vv8-ui).
This legacy UI standalone application could be used together with future hawkBit update server versions as long as it
is compatible and on the user's responsibility. Some notes for it:
* *NOT RECOMMENDED* - it might contain security vulnerabilities and bugs. It could be hard to verify its
compatibility with the new hawkBit versions.
* *ON USER's RESPONSIBILITY* - no guarantees of any kind are provided for that application. It is entirely the
user's responsibility to test, scan for vulnerabilities, and use it.
* Provides an option to use the legacy Vaadin 8 UI with the new hawkBit versions under the conditions above
* It uses directly the database and legacy update server code
* It includes the outdated Spring Boot 2.7 which is after its end of support
* It will not be developed any further and new features won't be available
* No bugfixes would be provided for it
### Extended access control management - entity-based
There is a new feature implemented in access control management. Up until now, permissions (e.g. CREATE_TARGET) were assigned to the users, and based on that users were able to execute some action or not. Now there is added a pluggable mechanism via [AccessController](https://github.com/eclipse-hawkbit/hawkbit/blob/0.4.1/hawkbit-repository/hawkbit-repository-jpa/src/main/java/org/eclipse/hawkbit/repository/jpa/acm/AccessController.java) that allows to further restrict the access based on the entity. For instance, a developer could implement its custom access controller for targets that, depending on the user, could grant or reject permissions for accessing targets of certain target types.
There is a new feature implemented in access control management. Up until now, permissions (e.g. CREATE_TARGET) were
assigned to the users, and based on that users were able to execute some action or not. Now there is added a pluggable
mechanism
via [AccessController](https://github.com/eclipse-hawkbit/hawkbit/blob/0.4.1/hawkbit-repository/hawkbit-repository-jpa/src/main/java/org/eclipse/hawkbit/repository/jpa/acm/AccessController.java)
that allows to further restrict the access based on the entity. For instance, a developer could implement its custom
access controller for targets that, depending on the user, could grant or reject permissions for accessing targets of
certain target types.

52
site/content/community.md
View File

@@ -5,41 +5,59 @@ weight: 90
## Presentations
Here you can find links to arbitrary material covering Eclipse hawkBit which has been presented at events, conferences and meet-ups.
Here you can find links to arbitrary material covering Eclipse hawkBit which has been presented at events, conferences
and meet-ups.
- 09/23/2015 - Eclipse IoT Working Group meeting - [slides](https://docs.bosch-iot-rollouts.com/slides/hawkBitProposal20150923.html)
- 09/23/2015 - Eclipse IoT Working Group
meeting - [slides](https://docs.bosch-iot-rollouts.com/slides/hawkBitProposal20150923.html)
- 04/11/2015 - EclipseCon Europe 2015 - [slides](https://docs.bosch-iot-rollouts.com/slides/eclipseCon2015.html)
- 03/09/2016 - EclipseCon North America 2016 - [slides](https://docs.bosch-iot-rollouts.com/slides/eclipseConNA2016.html)
- 05/16/2016 - Eclipse Virtual IoT Meetup - [video](https://www.youtube.com/watch?v=g-dhKMaaanE) - [slides](https://docs.bosch-iot-rollouts.com/slides/virtualIoTMeetup2016.html)
- 03/20/2017 - Eclipse IoT Day SanJose, CA - [video](https://www.youtube.com/watch?v=x5OfBgnYW44) - [slides](https://docs.bosch-iot-rollouts.com/slides/iotDaySanJose2017.pdf)
- 03/09/2016 - EclipseCon North America
2016 - [slides](https://docs.bosch-iot-rollouts.com/slides/eclipseConNA2016.html)
- 05/16/2016 - Eclipse Virtual IoT
Meetup - [video](https://www.youtube.com/watch?v=g-dhKMaaanE) - [slides](https://docs.bosch-iot-rollouts.com/slides/virtualIoTMeetup2016.html)
- 03/20/2017 - Eclipse IoT Day SanJose,
CA - [video](https://www.youtube.com/watch?v=x5OfBgnYW44) - [slides](https://docs.bosch-iot-rollouts.com/slides/iotDaySanJose2017.pdf)
- 09/12/2017 - Eclipse IoT Day ThingMonk 2017 - [video](https://www.youtube.com/watch?v=7hK-kiQjKGA)
- 01/10/2018 - Eclipse Virtual IoT Meetup - [video](https://www.youtube.com/watch?v=8vcLXs9lc-4) - [slides](https://docs.bosch-iot-rollouts.com/slides/hawkBitIntroduction.html)
- 10/22/2018 - Community Day EclipseCon Europe 2018 - [slides](https://www.eclipse.org/hawkbit/slides/community-day-2018.html)
- 10/21/2019 - Community Day EclipseCon Europe 2019 - [slides](https://www.eclipse.org/hawkbit/slides/community-day-2019.html)
- 10/19/2020 - Community Day EclipseCon Europe 2020 - [slides](https://www.eclipse.org/hawkbit/slides/community-day-2020.html)
- 01/10/2018 - Eclipse Virtual IoT
Meetup - [video](https://www.youtube.com/watch?v=8vcLXs9lc-4) - [slides](https://docs.bosch-iot-rollouts.com/slides/hawkBitIntroduction.html)
- 10/22/2018 - Community Day EclipseCon Europe
2018 - [slides](https://www.eclipse.org/hawkbit/slides/community-day-2018.html)
- 10/21/2019 - Community Day EclipseCon Europe
2019 - [slides](https://www.eclipse.org/hawkbit/slides/community-day-2019.html)
- 10/19/2020 - Community Day EclipseCon Europe
2020 - [slides](https://www.eclipse.org/hawkbit/slides/community-day-2020.html)
## Articles
- 10/27/2015 - Why software provisioning goes open source - [article](http://blog.bosch-si.com/categories/technology/2015/10/software-provisioning-goes-open-source-find/)
- 05/25/2016 - jaxenter: Eclipse hawkBit - [english](https://jaxenter.com/eclipse-hawkbit-126445.html) - [german](https://jaxenter.de/eclipse-hawkbit-46372)
- 09/27/2016 - Eclipse Newsletter - 'IoT is the new black' - [article](http://www.eclipse.org/community/eclipse_newsletter/2016/september/article2.php)
- 10/27/2015 - Why software provisioning goes open
source - [article](http://blog.bosch-si.com/categories/technology/2015/10/software-provisioning-goes-open-source-find/)
- 05/25/2016 - jaxenter: Eclipse
hawkBit - [english](https://jaxenter.com/eclipse-hawkbit-126445.html) - [german](https://jaxenter.de/eclipse-hawkbit-46372)
- 09/27/2016 - Eclipse Newsletter - 'IoT is the new
black' - [article](http://www.eclipse.org/community/eclipse_newsletter/2016/september/article2.php)
## Ask a question
Visit [stackoverflow.com](https://stackoverflow.com/questions/tagged/eclipse-hawkbit) to find questions or raise your own tagged with `eclipse-hawkbit`.
Visit [stackoverflow.com](https://stackoverflow.com/questions/tagged/eclipse-hawkbit) to find questions or raise your
own tagged with `eclipse-hawkbit`.
## Chat
Searching for a quick response from the team behind hawkBit and the hawkBit community, join the [Gitter Chat](https://gitter.im/eclipse/hawkbit).
Searching for a quick response from the team behind hawkBit and the hawkBit community, join
the [Gitter Chat](https://gitter.im/eclipse/hawkbit).
## Mailing List
A great way to stay up to date with hawkBit activity is to subscribe to the Mailing list provided by Eclipse. Sign up for the mailing list [here](https://dev.eclipse.org/mailman/listinfo/hawkbit-dev).
A great way to stay up to date with hawkBit activity is to subscribe to the Mailing list provided by Eclipse. Sign up
for the mailing list [here](https://dev.eclipse.org/mailman/listinfo/hawkbit-dev).
## Issue Tracker
Issues and bugs related to hawkBit are tracked with the Github Issue tracking system. If you find any issues, please report them [here](https://github.com/eclipse-hawkbit/hawkbit/issues).
Issues and bugs related to hawkBit are tracked with the Github Issue tracking system. If you find any issues, please
report them [here](https://github.com/eclipse-hawkbit/hawkbit/issues).
## Contributing
An overview of the contribution process is [here](https://wiki.eclipse.org/Development_Resources/Contributing_via_Git). Checkout the [Contribution Guidelines](https://github.com/eclipse-hawkbit/hawkbit/blob/master/CONTRIBUTING.md) on the Eclipse hawkBit GitHub Repository.
An overview of the contribution process is [here](https://wiki.eclipse.org/Development_Resources/Contributing_via_Git).
Checkout the [Contribution Guidelines](https://github.com/eclipse-hawkbit/hawkbit/blob/master/CONTRIBUTING.md) on the
Eclipse hawkBit GitHub Repository.

112
site/content/concepts/authentication.md
View File

@@ -9,17 +9,21 @@ A hawkBit update server can be accessed in four different ways:
- _Direct Device Integration (DDI) API_ by **targets**.
- _Management API_ by 3rd party **applications**.
- _Device Management Federation (DMF) API_ by 3rd party **applications** through AMQP.
<!--more-->
<!--more-->
## DDI API Authentication Modes
### Security Token
hawkBit supports multiple ways to authenticate a target against the server. The different authentication modes can be individual enabled and disabled within hawkBit. Both on system level (with Spring Boot properties) as per individual tenant.
hawkBit supports multiple ways to authenticate a target against the server. The different authentication modes can be
individual enabled and disabled within hawkBit. Both on system level (with Spring Boot properties) as per individual
tenant.
#### Target Security Token Authentication
There is a 32 alphanumeric character security-token for each created target within IoT hawkBit. This token can be used to authenticate the target at hawkBit through the HTTP-Authorization header with the custom scheme _TargetToken_.
There is a 32 alphanumeric character security-token for each created target within IoT hawkBit. This token can be used
to authenticate the target at hawkBit through the HTTP-Authorization header with the custom scheme _TargetToken_.
```
GET /SPDEMO/controller/v1/0e945f95-9117-4500-9b0a-9c6d72fa6c07 HTTP/1.1
@@ -27,18 +31,28 @@ Host: your.hawkBit.server
Authorization: TargetToken bH7XXAprK1ChnLfKSdtlsp7NOlPnZAYY
```
The target security token is provided in [DMF API](../../apis/dmf_api/) as part of the update message in order to allow DMF clients to leverage the feature or can it be manually retrieved per target by [Management API](../../apis/management_api/) or in the [Management UI](../../ui) in the target details.
The target security token is provided in [DMF API](../../apis/dmf_api/) as part of the update message in order to allow
DMF clients to leverage the feature or can it be manually retrieved per target
by [Management API](../../apis/management_api/) or in the [Management UI](../../ui) in the target details.
Note: needs to be enabled in your hawkBit installation **and** in the tenant configuration. That allows both the operator as well as the individual customer (if run in a multi-tenant setup) to enable this access method. See [DdiSecurityProperties](https://github.com/eclipse-hawkbit/hawkbit/blob/master/hawkbit-security-core/src/main/java/org/eclipse/hawkbit/security/DdiSecurityProperties.java) for system wide enablement.
Note: needs to be enabled in your hawkBit installation **and** in the tenant configuration. That allows both the
operator as well as the individual customer (if run in a multi-tenant setup) to enable this access method.
See [DdiSecurityProperties](https://github.com/eclipse-hawkbit/hawkbit/blob/master/hawkbit-security-core/src/main/java/org/eclipse/hawkbit/security/DdiSecurityProperties.java)
for system wide enablement.
The additional activation for the individual tenant:
![Enable Target Token](../../images/security/targetToken.png)
#### Gateway Security Token Authentication
Often the targets are connected through a gateway which manages the targets directly and as a result are indirectly connected to the hawkBit update server.
To authenticate this gateway and allow it to manage all target instances under its tenant there is a _GatewayToken_ to authenticate this gateway through the HTTP-Authorization header with a custom scheme _GatewayToken_. This is of course also handy during development or for testing purposes. However, we generally recommend to use this token with care as it allows to act _in the name of_ any device.
Often the targets are connected through a gateway which manages the targets directly and as a result are indirectly
connected to the hawkBit update server.
To authenticate this gateway and allow it to manage all target instances under its tenant there is a _GatewayToken_ to
authenticate this gateway through the HTTP-Authorization header with a custom scheme _GatewayToken_. This is of course
also handy during development or for testing purposes. However, we generally recommend to use this token with care as it
allows to act _in the name of_ any device.
```
GET /SPDEMO/controller/v1/0e945f95-9117-4500-9b0a-9c6d72fa6c07 HTTP/1.1
@@ -46,16 +60,24 @@ Host: your.hawkBit.server
Authorization: GatewayToken 3nkswAZhX81oDtktq0FF9Pn0Tc0UGXPW
```
Note: needs to be enabled in your hawkBit installation **and** in the tenant configuration. That allows both the operator as well as the individual customer (if run in a multi-tenant setup) to enable this access method. See [DdiSecurityProperties](https://github.com/eclipse-hawkbit/hawkbit/blob/master/hawkbit-security-core/src/main/java/org/eclipse/hawkbit/security/DdiSecurityProperties.java) for system wide enablement.
Note: needs to be enabled in your hawkBit installation **and** in the tenant configuration. That allows both the
operator as well as the individual customer (if run in a multi-tenant setup) to enable this access method.
See [DdiSecurityProperties](https://github.com/eclipse-hawkbit/hawkbit/blob/master/hawkbit-security-core/src/main/java/org/eclipse/hawkbit/security/DdiSecurityProperties.java)
for system wide enablement.
The additional activation for the individual tenant:
![Enable Gateway Token](../../images/security/gatewayToken.png)
#### Anonymous access
Here we offer general anonymous access for all targets (see [DdiSecurityProperties](https://github.com/eclipse-hawkbit/hawkbit/blob/master/hawkbit-security-core/src/main/java/org/eclipse/hawkbit/security/DdiSecurityProperties.java)) which we consider not really sufficient for a production system but it might come in handy to get a project started in the beginning.
However, anonymous download on the other side might be interesting even in production for scenarios where the artifact itself is already encrypted.
Here we offer general anonymous access for all targets (
see [DdiSecurityProperties](https://github.com/eclipse-hawkbit/hawkbit/blob/master/hawkbit-security-core/src/main/java/org/eclipse/hawkbit/security/DdiSecurityProperties.java))
which we consider not really sufficient for a production system but it might come in handy to get a project started in
the beginning.
However, anonymous download on the other side might be interesting even in production for scenarios where the artifact
itself is already encrypted.
The activation for the individual tenant:
@@ -63,15 +85,24 @@ The activation for the individual tenant:
### Certificate Authentication by Reverse Proxy
hawkBit offers a certificate-based authentication mechanism, also known as mutual TLS (mTLS), which eliminates the need to share a security token with the server. To implement this, you'll require a reverse proxy deployed in front of the hawkBit server to handle authentication. This process involves obtaining certificates (and keys) for both the client and the reverse proxy and configuring hawkBit accordingly.
hawkBit offers a certificate-based authentication mechanism, also known as mutual TLS (mTLS), which eliminates the need
to share a security token with the server. To implement this, you'll require a reverse proxy deployed in front of the
hawkBit server to handle authentication. This process involves obtaining certificates (and keys) for both the client and
the reverse proxy and configuring hawkBit accordingly.
Initially, you'll need to obtain certificates (and keys) for these components from the same or different Certificate Authorities (CAs). Once you have acquired certificates you have to set them up to both the client and the hawkBit server.
Initially, you'll need to obtain certificates (and keys) for these components from the same or different Certificate
Authorities (CAs). Once you have acquired certificates you have to set them up to both the client and the hawkBit
server.
Then you shall enable *Allow targets to authenticate via a certificate authenticated by a reverse proxy* and set the fingerprint of the client certificate issuer(s) (as a comma separated list).
Then you shall enable *Allow targets to authenticate via a certificate authenticated by a reverse proxy* and set the
fingerprint of the client certificate issuer(s) (as a comma separated list).
To authenticate the request to hawBit the following condition shall be met:
- the common name of the client certificate shall match the controller/client id
- the SSL Issuer(s) hash of the presented client certificate shall be set for the tenant. For that, in Hawkbit's UI section, under system configuration, you shall enable 'Allow targets to authenticate via a certificate by an reverse proxy' and set the hash of the client certificate issuer(s) (as a comma separated list).
- the SSL Issuer(s) hash of the presented client certificate shall be set for the tenant. For that, in Hawkbit's UI
section, under system configuration, you shall enable 'Allow targets to authenticate via a certificate by an reverse
proxy' and set the hash of the client certificate issuer(s) (as a comma separated list).
![Example Reverse Proxy Settings](../../images/security/exampleReverseProxySettings.png)
@@ -81,7 +112,8 @@ You can use the following command to get the issuer hash:
openssl x509 -in client_certificate.crt -issuer_hash -noout`
```
Here is an example diagram that shows all the communication between the hawkBit, reverse proxy and client. For the sake of simplification we assume that there are not intermediate certificates and the certificate and key are as follows:
Here is an example diagram that shows all the communication between the hawkBit, reverse proxy and client. For the sake
of simplification we assume that there are not intermediate certificates and the certificate and key are as follows:
- client_ca.crt signs client.crt
- server_ca.crt signs server.crt
@@ -93,25 +125,37 @@ Here is an example diagram that shows all the communication between the hawkBit,
#### Example - Nginx Reverse Proxy Configurations
Nginx doesn't support obtaining the issuer hash without addons. Therefore, in this example we bypass sending real SSL Issuer hash to hawhBit but do certificate issuer validation at Nginx and then supply shared (between Nginx and hawkBit) fixed hash "Hawkbit". You could use any value here as long as it is matched with the *Allow targets to authenticate via a certificate authenticated by a reverse proxy* setting in the hawkBit UI. Note that for multi-tenant scenarios with different trusted CAs this example won't work.
Nginx doesn't support obtaining the issuer hash without addons. Therefore, in this example we bypass sending real SSL
Issuer hash to hawhBit but do certificate issuer validation at Nginx and then supply shared (between Nginx and hawkBit)
fixed hash "Hawkbit". You could use any value here as long as it is matched with the *Allow targets to authenticate via
a certificate authenticated by a reverse proxy* setting in the hawkBit UI. Note that for multi-tenant scenarios with
different trusted CAs this example won't work.
1. Hawkbit Configurations
There are also some configurations that you need update when you deployed your hawkbit service.
You need to add the given setting to your hawkBit configurations so that hawkBit can generate the URLs according to the https that the client will use to download. If you're deploying hawkBit as a Docker container, add these configurations as environmental values in the docker-compose.yml file.
You need to add the given setting to your hawkBit configurations so that hawkBit can generate the URLs according to
the https that the client will use to download. If you're deploying hawkBit as a Docker container, add these
configurations as environmental values in the docker-compose.yml file.
```
server.forward-headers-strategy=NATIVE
```
2. In Hawkbit's UI section, under system configuration, make sure to select *Allow targets to authenticate via a certificate authenticated by a reverse proxy* and input the fixed issuer hash as "Hawkbit". This can be whetever you have configured in the nginx configuration in `proxy_set_header X-Ssl-Issuer-Hash-1` below.
2. In Hawkbit's UI section, under system configuration, make sure to select *Allow targets to authenticate via a
certificate authenticated by a reverse proxy* and input the fixed issuer hash as "Hawkbit". This can be whetever you
have configured in the nginx configuration in `proxy_set_header X-Ssl-Issuer-Hash-1` below.
3. After placing your certificates and keys, you need to deploy your proxy server and apply the provided configurations. You can apply mutual TLS specifically to the URL given below to implement the process only for devices using the Device Integration API:
3. After placing your certificates and keys, you need to deploy your proxy server and apply the provided configurations.
You can apply mutual TLS specifically to the URL given below to implement the process only for devices using the
Device Integration API:
`hawkbit.dev.example.com/default/controller/`
`hawkbit.dev.example.com/default/controller/`
This ensures that other clients, like UI users, can connect to hawkBit without requiring client certificates. They can use Username and Password in the Management API, eliminating the need for authentication and making it more user-friendly.
This ensures that other clients, like UI users, can connect to hawkBit without requiring client certificates. They
can use Username and Password in the Management API, eliminating the need for authentication and making it more
user-friendly.
```nginx
# Nginx Hawkbit Configurations
@@ -185,7 +229,7 @@ server {
}
}
```
4. To deploy Nginx, you could use a `.yml` file. Here's an example `docker-compose.yml` file for Nginx Docker.
```yml
@@ -210,14 +254,21 @@ services:
- ./certbot/www/:/var/www/certbot/:rw
- ./certbot/conf/:/etc/letsencrypt/:rw
```
`/client-cer/:/etc/nginx/client-cer/` is the designated location for the certificate authority that has signed the client certificate. The presented client certificate will be verified against this CA.
5. After successfully generating your certificates with the correct chain, deploying your Nginx and Hawkbit services with appropriate configurations, and updating the settings on the device side, you will be able to establish a certificate-based authentication mechanism. This will eliminate the necessity of sharing a security token with the server.
`/client-cer/:/etc/nginx/client-cer/` is the designated location for the certificate authority that has signed the
client certificate. The presented client certificate will be verified against this CA.
5. After successfully generating your certificates with the correct chain, deploying your Nginx and Hawkbit services
with appropriate configurations, and updating the settings on the device side, you will be able to establish a
certificate-based authentication mechanism. This will eliminate the necessity of sharing a security token with the
server.
&nbsp;
##### Swupdate Suricatta Configurations
If the client is utilizing the SWUpdate Suricatta service, the configurations on the device or client side should also be adjusted as follows. Remember to change id, url and certificate names to your needs.
If the client is utilizing the SWUpdate Suricatta service, the configurations on the device or client side should also
be adjusted as follows. Remember to change id, url and certificate names to your needs.
The location of the config file is `/etc/swupdate/swupdate.conf`
@@ -241,6 +292,7 @@ journalctl --follow -u swupdate
```
&nbsp;
##### Testing
You can test the communication by using the Curl command below to see if you successfully implemented mutual TLS:
@@ -249,14 +301,18 @@ You can test the communication by using the Curl command below to see if you suc
curl -L -v --cert client.crt --key client.key --cacert server_ca.crt https://hawkbit.dev.example.com/default/controller/v1/{device-id}
```
In the UI, after uploading an SWU package and requesting a firmware update, you can use the link below to attempt to install the software package.
In the UI, after uploading an SWU package and requesting a firmware update, you can use the link below to attempt to
install the software package.
```
curl -L -v --cert client.crt --key client.key --cacert server_ca.crt https://hawkbit.dev.example.com/default/controller/v1/{device-id}/softwaremodules/{artifact-id}/artifacts/hawkbit_updated_5.swu --output outputfile
```
## DMF API
Authentication is provided by _RabbitMQ_ [vhost and user credentials](https://www.rabbitmq.com/access-control.html) that is used for the integration.
Authentication is provided by _RabbitMQ_ [vhost and user credentials](https://www.rabbitmq.com/access-control.html) that
is used for the integration.
## Management API
- Basic Auth

69
site/content/concepts/authorization.md
View File

@@ -4,12 +4,22 @@ parent: Concepts
weight: 52
---
Authorization is handled separately for _Direct Device Integration (DDI) API_ and _Device Management Federation (DMF) API_ (where successful authentication includes full authorization) and _Management API_ and _UI_ which is based on Spring security [authorities](https://github.com/eclipse-hawkbit/hawkbit/blob/master/hawkbit-security-core/src/main/java/org/eclipse/hawkbit/im/authentication/SpPermission.java).
Authorization is handled separately for _Direct Device Integration (DDI) API_ and _Device Management Federation (DMF)
API_ (where successful authentication includes full authorization) and _Management API_ and _UI_ which is based on
Spring
security [authorities](https://github.com/eclipse-hawkbit/hawkbit/blob/master/hawkbit-security-core/src/main/java/org/eclipse/hawkbit/im/authentication/SpPermission.java).
<!--more-->
However, keep in mind that hawkBit does not offer an off the shelf authentication provider to leverage these permissions and the underlying multi user/tenant capabilities of hawkBit but it supports authentication providers offering an OpenID Connect interface. Check out [Spring security documentation](http://projects.spring.io/spring-security/) for further information. In hawkBit [SecurityAutoConfiguration](https://github.com/eclipse-hawkbit/hawkbit/blob/master/hawkbit-autoconfigure/src/main/java/org/eclipse/hawkbit/autoconfigure/security/SecurityAutoConfiguration.java) is a good starting point for integration.
However, keep in mind that hawkBit does not offer an off the shelf authentication provider to leverage these permissions
and the underlying multi user/tenant capabilities of hawkBit but it supports authentication providers offering an OpenID
Connect interface. Check out [Spring security documentation](http://projects.spring.io/spring-security/) for further
information. In
hawkBit [SecurityAutoConfiguration](https://github.com/eclipse-hawkbit/hawkbit/blob/master/hawkbit-autoconfigure/src/main/java/org/eclipse/hawkbit/autoconfigure/security/SecurityAutoConfiguration.java)
is a good starting point for integration.
The default implementation is single user/tenant with basic auth and the logged in user is provided with all permissions. Additionally, the application properties may be configured for multiple static users; see [Multiple Users](#multiple-users) for details.
The default implementation is single user/tenant with basic auth and the logged in user is provided with all
permissions. Additionally, the application properties may be configured for multiple static users;
see [Multiple Users](#multiple-users) for details.
## DDI API
@@ -19,13 +29,16 @@ An authenticated target is permitted to:
- provide feedback to the the server
- download artifacts that are assigned to it
A target might be permitted to download artifacts without authentication (if enabled, see above). Only the download can be permitted to disable the authentication. This can be used in scenarios where the artifacts itself are e.g. signed and secured.
A target might be permitted to download artifacts without authentication (if enabled, see above). Only the download can
be permitted to disable the authentication. This can be used in scenarios where the artifacts itself are e.g. signed and
secured.
## Management API and UI
### Multiple Users
hawkBit optionally supports configuring multiple static users through the application properties. In this case, the user and password Spring security properties are ignored.
hawkBit optionally supports configuring multiple static users through the application properties. In this case, the user
and password Spring security properties are ignored.
An example configuration is given below.
hawkbit.server.im.users[0].username=admin
@@ -42,46 +55,54 @@ An example configuration is given below.
hawkbit.server.im.users[1].email=test@tester.com
hawkbit.server.im.users[1].permissions=READ_TARGET,UPDATE_TARGET,CREATE_TARGET,DELETE_TARGET
A permissions value of `ALL` will provide that user with all possible permissions. Passwords need to be specified with the used password encoder in brackets. In this example, `noop` is used as the plaintext encoder. For production use, it is recommended to use a hash function designed for passwords such as *bcrypt*. See this [blog post](https://spring.io/blog/2017/11/01/spring-security-5-0-0-rc1-released#password-storage-format) for more information on password encoders in Spring Security.
A permissions value of `ALL` will provide that user with all possible permissions. Passwords need to be specified with
the used password encoder in brackets. In this example, `noop` is used as the plaintext encoder. For production use, it
is recommended to use a hash function designed for passwords such as *bcrypt*. See
this [blog post](https://spring.io/blog/2017/11/01/spring-security-5-0-0-rc1-released#password-storage-format) for more
information on password encoders in Spring Security.
### OpenID Connect
hawkbit supports authentication providers which use the OpenID Connect standard, an authentication layer built on top of the OAuth 2.0 protocol.
hawkbit supports authentication providers which use the OpenID Connect standard, an authentication layer built on top of
the OAuth 2.0 protocol.
An example configuration is given below.
spring.security.oauth2.client.registration.oidc.client-id=clientID
spring.security.oauth2.client.provider.oidc.issuer-uri=https://oidc-provider/issuer-uri
spring.security.oauth2.client.provider.oidc.jwk-set-uri=https://oidc-provider/jwk-set-uri
Note: at the moment only DEFAULT tenant is supported. By default the resource_access/<client id>/roles claim is mapped to hawkBit permissions. However, by registering a Spring bean _org.eclipse.hawkbit.autoconfigure.security.OidcUserManagementAutoConfiguration.JwtAuthoritiesExtractor_ a custom extractor permission mapper could be registered.
Note: at the moment only DEFAULT tenant is supported. By default the resource_access/<client id>/roles claim is mapped
to hawkBit permissions. However, by registering a Spring bean
_org.eclipse.hawkbit.autoconfigure.security.OidcUserManagementAutoConfiguration.JwtAuthoritiesExtractor_ a custom
extractor permission mapper could be registered.
### Delivered Permissions
- READ_/UPDATE_/CREATE_/DELETE_TARGET for:
- Target entities including metadata (that includes also the installed and assigned distribution sets)
- Target tags
- Target actions
- Target registration rules
- Bulk operations
- Target filters
- Target entities including metadata (that includes also the installed and assigned distribution sets)
- Target tags
- Target actions
- Target registration rules
- Bulk operations
- Target filters
- READ_/UPDATE_/CREATE_/DELETE_REPOSITORY for:
- Distribution sets
- Software Modules
- Artifacts
- DS tags
- Distribution sets
- Software Modules
- Artifacts
- DS tags
- READ_TARGET_SECURITY_TOKEN
- Permission to read the target security token. The security token is security concerned and should be protected.
- Permission to read the target security token. The security token is security concerned and should be protected.
- DOWNLOAD_REPOSITORY_ARTIFACT
- Permission to download artifacts of a software module (Note: READ_REPOSITORY allows only to read the metadata).
- Permission to download artifacts of a software module (Note: READ_REPOSITORY allows only to read the metadata).
- TENANT_CONFIGURATION
- Permission to administrate the tenant settings.
- Permission to administrate the tenant settings.
- READ_/UPDATE_/CREATE_/DELETE_/HANDLE_/APPROVE_ROLLOUT for:
- Managing rollouts and provision targets through a rollout.
- Managing rollouts and provision targets through a rollout.
### Permission Matrix for example uses cases that need more than one permission
@@ -95,4 +116,6 @@ Note: at the moment only DEFAULT tenant is supported. By default the resource_ac
## Device Management Federation API
The provided _RabbitMQ_ [vhost and user](https://www.rabbitmq.com/access-control.html) should be provided with the necessary permissions to send messages to hawkBit through the exchange and receive messages from it through the specified queue.
The provided _RabbitMQ_ [vhost and user](https://www.rabbitmq.com/access-control.html) should be provided with the
necessary permissions to send messages to hawkBit through the exchange and receive messages from it through the
specified queue.

52
site/content/concepts/datamodel.md
View File

@@ -4,18 +4,30 @@ parent: Concepts
weight: 53
---
The hawkBit data model was designed to have enough flexibility to define complex software structures (e.g. operating system, runtimes, apps, different kind of artifacts) on one side and simplicity compared to the capabilities of a full blown configuration management on the other.
The hawkBit data model was designed to have enough flexibility to define complex software structures (e.g. operating
system, runtimes, apps, different kind of artifacts) on one side and simplicity compared to the capabilities of a full
blown configuration management on the other.
<!--more-->
It does define a hierarchy of software that starts with a distribution, which can have (sub-)modules and these may have multiple artifacts. However, it does not consider any kind of dependency definitions between modules or artifacts. As a result, dependency checks - if necessary - have to be done outside hawkBit, i.e. on the device itself or before the entity creation in hawkBit by the origin.
It does define a hierarchy of software that starts with a distribution, which can have (sub-)modules and these may have
multiple artifacts. However, it does not consider any kind of dependency definitions between modules or artifacts. As a
result, dependency checks - if necessary - have to be done outside hawkBit, i.e. on the device itself or before the
entity creation in hawkBit by the origin.
## Provisioning Target Definition
A Provisioning Target is a neutral definition that may be an actual real device (e.g. gateway, embedded sensor) or a virtual device (e.g. vehicle, smart home).
A Provisioning Target is a neutral definition that may be an actual real device (e.g. gateway, embedded sensor) or a
virtual device (e.g. vehicle, smart home).
The definition in hawkBit might reflect the transactional behavior if necessary on the device side. A vehicle might be updated device by device or as a whole. As a result one way of defining a vehicle in hawkBit could be to have one all inclusive Software Module or one module per (sub-) device.
The definition in hawkBit might reflect the transactional behavior if necessary on the device side. A vehicle might be
updated device by device or as a whole. As a result one way of defining a vehicle in hawkBit could be to have one all
inclusive Software Module or one module per (sub-) device.
A Target can have, next to its defined properties (e.g. controller ID, target type, name, description, security token), a generic set of attributes and meta data, both in key:value format. Target attributes are owned and managed by the device whereas target meta data are managed by the operator. If a target is defined to be of a certain target type, then during the assignment of a distribution set, a compatibility check will be performed between the target type and distribution set type.
A Target can have, next to its defined properties (e.g. controller ID, target type, name, description, security token),
a generic set of attributes and meta data, both in key:value format. Target attributes are owned and managed by the
device whereas target meta data are managed by the operator. If a target is defined to be of a certain target type, then
during the assignment of a distribution set, a compatibility check will be performed between the target type and
distribution set type.
## Software Structure Definition
@@ -23,28 +35,38 @@ The structure defines the model of the supported software by the provisioning ta
- Distribution Set Type:defines a package structure that is supported by certain devices
- Consists of Software Module Types both for
- Firmware - device can have only one module of that type (e.g. the operating system)
- Software - device can have multiple modules of that type (e.g. "Apps")
- Firmware - device can have only one module of that type (e.g. the operating system)
- Software - device can have multiple modules of that type (e.g. "Apps")
Software Content Definition:
- Distribution Set: can be deployed to a provisioning target
- Software Module: is a sub element of the distribution, e.g. OS, application, firmware X, firmware Y
- Artifact: binaries for a software module. Note: the decision which artifacts have to be downloaded are done on the device side, e.g. Full package, signatures, binary deltas
- Artifact: binaries for a software module. Note: the decision which artifacts have to be downloaded are done on the
device side, e.g. Full package, signatures, binary deltas
## Entity Relationships
The public defined entities and their relation which are reflected by the Management API.
## Deleting and Archiving Software Modules
When a user deletes a Software Module, the update server cannot simply remove all the corresponding data. Because when the Software Module is already assigned to a Distribution Set or was assigned to a Target in the past, the hawkBit server has to make sure that remains a clean and full update history for every target. The history contains all information (e.g. name, version) of the software, which was assigned to a specific Target. Obviously storing the binary data of the artifacts is not necessary for the history purpose.
The delete process which is performed, when there are historical connections to targets is called SoftDelete. This process marks the Software Module as deleted and removes the artifact, but it won't delete the meta data, which describes the SoftwareModule and the associated Artifacts. SoftwareModules, which are marked as delete won't be visible for the user, when he is requesting all SoftwareModules.
When a user deletes a Software Module, the update server cannot simply remove all the corresponding data. Because when
the Software Module is already assigned to a Distribution Set or was assigned to a Target in the past, the hawkBit
server has to make sure that remains a clean and full update history for every target. The history contains all
information (e.g. name, version) of the software, which was assigned to a specific Target. Obviously storing the binary
data of the artifacts is not necessary for the history purpose.
Just in case there are no connections to Distribution Sets and targets the server will perform a HardDelete. This process deletes all stored data, including all meta information.
The delete process which is performed, when there are historical connections to targets is called SoftDelete. This
process marks the Software Module as deleted and removes the artifact, but it won't delete the meta data, which
describes the SoftwareModule and the associated Artifacts. SoftwareModules, which are marked as delete won't be visible
for the user, when he is requesting all SoftwareModules.
Just in case there are no connections to Distribution Sets and targets the server will perform a HardDelete. This
process deletes all stored data, including all meta information.
{{% note %}}
In case of a SoftDelete the unique constraints are still in place, i.e. you cannot create an entity with the same name/key. This constraint might be removed in future versions because of the impact on the user experience (i.e. he does not see the soft deleted module but cannot create a new one).
In case of a SoftDelete the unique constraints are still in place, i.e. you cannot create an entity with the same
name/key. This constraint might be removed in future versions because of the impact on the user experience (i.e. he does
not see the soft deleted module but cannot create a new one).
{{% /note %}}

55
site/content/concepts/rollout-management.md
View File

@@ -12,9 +12,9 @@ That includes:
- _Technical Scalability_ by means of horizontal scale of the hawkBit server cluster in the cloud.
- _Global_ artifact _content delivery_ capacities.
- _Functional Scalability_ by means of:
- Secure handling of large volumes of devices at rollout creation time.
- Monitoring of the rollout progress.
- Emergency rollout shutdown in case of problems on to many devices.
- Secure handling of large volumes of devices at rollout creation time.
- Monitoring of the rollout progress.
- Emergency rollout shutdown in case of problems on to many devices.
- Reporting capabilities for a complete understanding of the rollout progress at each point in time.
@@ -23,44 +23,58 @@ Eclipse hawkBit sees these capabilities under the term Rollout Management.
The following capabilities are currently supported by the _Rollout Management_:
- Create, update and start of rollouts.
- Selection of targets as input for the rollout based on _target filter_ functionality.
- Selection of a _DistributionSet_.
- Auto-splitting of the input target list into a defined number deployment groups.
- Selection of targets as input for the rollout based on _target filter_ functionality.
- Selection of a _DistributionSet_.
- Auto-splitting of the input target list into a defined number deployment groups.
- Approval workflow
- Has to be enabled explicitly in configuration.
- Enables a workflow that requires a user with adequate permissions to review any new or updated rollout before it
can be started.
- Allows integration with 3rd party workflow engines.
- Has to be enabled explicitly in configuration.
- Enables a workflow that requires a user with adequate permissions to review any new or updated rollout before it
can be started.
- Allows integration with 3rd party workflow engines.
- Cascading start of the deployment groups based on installation status of the previous group.
- Emergency shutdown of the rollout in case a group exceeds the defined error threshold.
- Rollout progress monitoring for the entire rollout and the individual groups.
## Cascading Deployment Group Execution
The cascading execution of the deployment groups is based on two thresholds that can be defined by the rollout creator.
- success condition by means of percentage of successfully installed targets in the current groups triggers.
- error condition by means of absolute or percentage of failed installations which triggers an emergency shutdown of the entire rollout.
- error condition by means of absolute or percentage of failed installations which triggers an emergency shutdown of the
entire rollout.
## Rollout state machine
### State Machine on Rollout
![](../../images/rolloutstatediagram.png)
### State Machine on Rollout Deployment Group
![](../../images/rolloutgroupstatediagram.png)
## Multi-Assignments (beta)
One of the main paradigms of Eclipse hawkBit is, that a Distribution Set represents the currently installed software of a device. Hence, a device can have only one Distribution Set assigned/installed at a time. With _Multi-Assignments_ enabled, this paradigm shifts. Multi-Assignments allows to assign multiple Distribution Sets to a device simultaneously, without cancelling each other. As a consequence, an operator can trigger multiple campaigns addressing the same devices in parallel.
One of the main paradigms of Eclipse hawkBit is, that a Distribution Set represents the currently installed software of
a device. Hence, a device can have only one Distribution Set assigned/installed at a time. With _Multi-Assignments_
enabled, this paradigm shifts. Multi-Assignments allows to assign multiple Distribution Sets to a device simultaneously,
without cancelling each other. As a consequence, an operator can trigger multiple campaigns addressing the same devices
in parallel.
### Action weight
To differentiate between important and less important updates a property called _weight_ is used. When multi-assignments is enabled every action has a weight value between (and including) 0 and 1000. The higher the weight the more important is the assignment represented by the action. Also when defining a _rollout_ or an _auto-assignment_ and multi-assignments is enabled a weight value has to be provided. This value is passed to the actions created during the execution of these _rollouts_ and _auto-assignments_. If no weight was provided the highest value of 1000 is used instead.
To differentiate between important and less important updates a property called _weight_ is used. When multi-assignments
is enabled every action has a weight value between (and including) 0 and 1000. The higher the weight the more important
is the assignment represented by the action. Also when defining a _rollout_ or an _auto-assignment_ and
multi-assignments is enabled a weight value has to be provided. This value is passed to the actions created during the
execution of these _rollouts_ and _auto-assignments_. If no weight was provided the highest value of 1000 is used
instead.
### Consequences
While this feature provides more flexibility to the user and enables new use-cases, there are also some consequences one should be aware of:
While this feature provides more flexibility to the user and enables new use-cases, there are also some consequences one
should be aware of:
**Critical**
@@ -69,9 +83,12 @@ While this feature provides more flexibility to the user and enables new use-cas
**Minor**
* While on DMF-API a MULTI_ACTION request is sent, DDI-API only exposes the next action which has the highest priority in the list of open actions(according to their weight property).
* All information regarding the currently assigned or installed Distribution Set does only respect the last assignment, as well as the last successfully installed Distribution set. This also affects:
* While on DMF-API a MULTI_ACTION request is sent, DDI-API only exposes the next action which has the highest priority
in the list of open actions(according to their weight property).
* All information regarding the currently assigned or installed Distribution Set does only respect the last assignment,
as well as the last successfully installed Distribution set. This also affects:
* Pinning a target or Distribution Set in Deployment View.
* Statistics about installed or assigned Distribution Sets.
* Auto close running actions, when a new Distribution Set is assigned (`repository.actions.autoclose.enabled`) is deactivated.
* Auto close running actions, when a new Distribution Set is assigned (`repository.actions.autoclose.enabled`) is
deactivated.
* Marking a Distribution Set to be a *Required Migration Step* is deactivated.

6
site/content/concepts/targetstate.md
View File

@@ -4,7 +4,10 @@ parent: Concepts
weight: 55
---
A target has a current state which reflects the provisioning status of the device at this point in time. State changes are driven either by the update server by means of starting an update or by the controller on the provisioning target that gives feedback to the update server, e.g. "I am here", "I am working on a provisioning", "I have finished a provisioning".
A target has a current state which reflects the provisioning status of the device at this point in time. State changes
are driven either by the update server by means of starting an update or by the controller on the provisioning target
that gives feedback to the update server, e.g. "I am here", "I am working on a provisioning", "I have finished a
provisioning".
<!--more-->
## Defined states
@@ -18,4 +21,5 @@ A target has a current state which reflects the provisioning status of the devic
| REGISTERED | Target registered at the update server but no _Distribution Set_ assigned. Is the initial starting point for plug-and-play devices. |
## Transitions
![](../../images/architecture/targetStatusStates.png)

19
site/content/features.md
View File

@@ -3,30 +3,35 @@ title: Features
weight: 40
---
## Device and Software Repository
- Repository that holds the provisioning targets and assignable software distributions.
- Targets to be logically grouped by Target Types.
- That includes a full software update history for every device.
- Support for pre-commission devices in the repository and plug and play, i.e. device is created if it is authenticated for the first time.
- Support for pre-commission devices in the repository and plug and play, i.e. device is created if it is authenticated
for the first time.
## Update Management
- Directly deploy a defined software distribution to a device (by Management API).
- Update handling is independent of the device type, integration approach or connectivity.
- Optional user consent flow, download and install updates only after respective end user has confirmed it.
- Optional user consent flow, download and install updates only after respective end user has confirmed it.
- Mass cancel the distribution of an update by invalidating the distribution set.
- Use action status codes for easier analysis.
## Artifact Content Delivery
- Partial downloads supported.
- Download resume supported (RFC7233).
- Content management by RESTful API and UI (see above).
- Authorization based on software assignment, i.e. a device can only download what has been assigned to it in the first place.
- Authorization based on software assignment, i.e. a device can only download what has been assigned to it in the first
place.
- Delta artifact hosting supported.
- Artifact signature hosting supported.
- Plug-point for artifact encryption allowing to encrypt artifacts on upload.
## Rollout/Campaign Management
- Secure handling of large volumes of devices at rollout creation time.
- Flexible deployment group definition as part of a rollout.
- Monitoring of the rollout progress.
@@ -36,6 +41,7 @@ weight: 40
## Interfaces
### Management API
- RESTful API
- Create/Read/Update/Delete operations for provisioning targets (i.e. devices) and repository content (i.e. software).
- Manage and monitor software update operations.
@@ -44,6 +50,7 @@ weight: 40
- Supports filtering, sorting and paging.
### Direct Device Integration API
- RESTful HTTP based API for direct device integration
- JSON payload.
- Traffic optimized (content based Etag generation, not modified).
@@ -51,7 +58,9 @@ weight: 40
- TLS encryption.
### Device Management Federation API
- Indirect device integration through a device management service or application into hawkBit.
- Optimized for high service to service throughput with [AMQP](https://www.rabbitmq.com/amqp-0-9-1-reference.html) messaging interface.
- Optimized for high service to service throughput with [AMQP](https://www.rabbitmq.com/amqp-0-9-1-reference.html)
messaging interface.
- Separate AMQP vHost per tenant for maximum security.

11
site/content/gettingstarted.md
View File

@@ -16,17 +16,20 @@ any personal data.
In addition, the following vendors offer free trial accounts for their Eclipse hawkBit compatible products:
* [Bosch IoT Rollouts](https://bosch-iot-suite.com/service/rollouts/) (by [Bosch Digital](https://www.bosch-digital.com))
* [Bosch IoT Rollouts](https://bosch-iot-suite.com/service/rollouts/) (
by [Bosch Digital](https://www.bosch-digital.com))
* [Kynetics Update Factory](https://www.kynetics.com/update-factory) (by [Kynetics LLC](https://www.kynetics.com/))
## From Docker Image
### Overview
HawkBit Update Server username/password -> admin/admin as default login credentials. They can be overridden by the environment variables spring.security.user.name and spring.security.user.password which are defined in the corresponding default [application.properties](hawkbit-runtime/hawkbit-update-server/src/main/resources/application.properties).
HawkBit Update Server username/password -> admin/admin as default login credentials. They can be overridden by the
environment variables spring.security.user.name and spring.security.user.password which are defined in the corresponding
default [application.properties](hawkbit-runtime/hawkbit-update-server/src/main/resources/application.properties).
It supports two configurations:
* monolith - hawkbit-update-server
* micro-service - hawkbit-mgmt-server, hawkbit-ddi-server, hawkbit-dmf-server.
@@ -61,6 +64,7 @@ $ docker-compose -f docker-compose-micro-service-mysql.yml up -d
## From Sources
### 1: Clone and build hawkBit
```sh
$ git clone https://github.com/eclipse-hawkbit/hawkbit.git
$ cd hawkbit
@@ -82,6 +86,7 @@ $ mvn clean install
```
### 4: Start hawkBit [Device Simulator](https://github.com/eclipse-hawkbit/hawkbit-examples/tree/master/hawkbit-device-simulator)
```sh
$ java -jar ./hawkbit-device-simulator/target/hawkbit-device-simulator-#version#.jar
```

30
site/content/guides/clustering.md
View File

@@ -4,7 +4,9 @@ parent: Guides
weight: 33
---
hawkBit is able to run in a cluster with some constraints. This guide provides insights in the basic concepts and how to setup your own cluster. You can find additional information in the [hawkBit runtimes's README](https://github.com/eclipse-hawkbit/hawkbit/blob/master/hawkbit-runtime/hawkbit-update-server/README.md).
hawkBit is able to run in a cluster with some constraints. This guide provides insights in the basic concepts and how to
setup your own cluster. You can find additional information in
the [hawkBit runtimes's README](https://github.com/eclipse-hawkbit/hawkbit/blob/master/hawkbit-runtime/hawkbit-update-server/README.md).
<!--more-->
## Big picture
@@ -13,8 +15,13 @@ hawkBit is able to run in a cluster with some constraints. This guide provides i
## Events
Event communication between nodes is based on [Spring Cloud Bus](https://cloud.spring.io/spring-cloud-bus/) and [Spring Cloud Stream](http://docs.spring.io/spring-cloud-stream/docs/current/reference/htmlsingle/). There are different [binder implementations](http://docs.spring.io/spring-cloud-stream/docs/current/reference/htmlsingle/#_binders) available. The _hawkbit Update Server_ uses RabbitMQ binder. Every node gets his own queue to receive cluster events, the default payload is JSON.
If an event is thrown locally at one node, it will be automatically delivered to all other available nodes via the Spring Cloud Bus's topic exchange:
Event communication between nodes is based on [Spring Cloud Bus](https://cloud.spring.io/spring-cloud-bus/)
and [Spring Cloud Stream](http://docs.spring.io/spring-cloud-stream/docs/current/reference/htmlsingle/). There are
different [binder implementations](http://docs.spring.io/spring-cloud-stream/docs/current/reference/htmlsingle/#_binders)
available. The _hawkbit Update Server_ uses RabbitMQ binder. Every node gets his own queue to receive cluster events,
the default payload is JSON.
If an event is thrown locally at one node, it will be automatically delivered to all other available nodes via the
Spring Cloud Bus's topic exchange:
![](../../images/eventing-within-cluster.png)
@@ -23,16 +30,25 @@ Via the ServiceMatcher you can check whether an event happened locally at one no
## Caching
Every node is maintaining its own caches independent from other nodes. So there is no globally shared/synchronized cache instance within the cluster. In order to keep nodes in sync a TTL (time to live) can be set for all caches to ensure that after some time the cache is refreshed from the database. To enable the TTL just set the property "hawkbit.cache.global.ttl" (value in milliseconds). Of course you can implement a shared cache, e.g. Redis.
Every node is maintaining its own caches independent from other nodes. So there is no globally shared/synchronized cache
instance within the cluster. In order to keep nodes in sync a TTL (time to live) can be set for all caches to ensure
that after some time the cache is refreshed from the database. To enable the TTL just set the property "
hawkbit.cache.global.ttl" (value in milliseconds). Of course you can implement a shared cache, e.g. Redis.
See [CacheAutoConfiguration](https://github.com/eclipse-hawkbit/hawkbit/blob/master/hawkbit-autoconfigure/src/main/java/org/eclipse/hawkbit/autoconfigure/cache/CacheAutoConfiguration.java)
## Schedulers
Every node has multiple schedulers which run after a defined period of time. All schedulers always run on every node. This has to be kept in mind e.g. if the scheduler executes critical code which has to be executed only once.
Every node has multiple schedulers which run after a defined period of time. All schedulers always run on every node.
This has to be kept in mind e.g. if the scheduler executes critical code which has to be executed only once.
## Known constraints
### Denial-of-Service (DoS) filter
hawkBit owns the feature of guarding itself from DoS attacks, a [DoS filter](https://github.com/eclipse-hawkbit/hawkbit/blob/master/hawkbit-http-security/src/main/java/org/eclipse/hawkbit/security/DosFilter.java). It reduces the maximum number of requests per seconds which can be configured for read and write requests.
This mechanism is only working for every node separately, i.e. in a cluster environment the worst-case behaviour would be that the maximum number of requests per seconds will be increased to its product if every request is handled by a different node.
hawkBit owns the feature of guarding itself from DoS attacks,
a [DoS filter](https://github.com/eclipse-hawkbit/hawkbit/blob/master/hawkbit-http-security/src/main/java/org/eclipse/hawkbit/security/DosFilter.java).
It reduces the maximum number of requests per seconds which can be configured for read and write requests.
This mechanism is only working for every node separately, i.e. in a cluster environment the worst-case behaviour would
be that the maximum number of requests per seconds will be increased to its product if every request is handled by a
different node.
The same constraint exists with the validator to check if a user tried too many logins within a defined period of time.

28
site/content/guides/feignclient.md
View File

@@ -4,18 +4,31 @@ parent: Guides
weight: 32
---
In this guide we describe how to create a [Feign](https://github.com/Netflix/feign) Rest Client based on a [Spring Boot](http://projects.spring.io/spring-boot/) Application.
In this guide we describe how to create a [Feign](https://github.com/Netflix/feign) Rest Client based on
a [Spring Boot](http://projects.spring.io/spring-boot/) Application.
<!--more-->
## Create Feign REST Client
hawkBit provides REST interfaces for [Management API](https://github.com/eclipse-hawkbit/hawkbit/tree/master/hawkbit-ddi-api) and [DDI API](https://github.com/eclipse-hawkbit/hawkbit/tree/master/hawkbit-ddi-api). Using this interfaces you can create a feign client with the help of the [feign inheritance support](http://projects.spring.io/spring-cloud/spring-cloud.html#spring-cloud-feign-inheritance).
Our [example](https://github.com/eclipse-hawkbit/hawkbit-examples) modules demonstrate how to create [Feign](https://github.com/Netflix/feign) client resources. Here you can find the [Management API client resources](hhttps://github.com/eclipse-hawkbit/hawkbit-examples/tree/master/hawkbit-example-mgmt-feign-client) and the [DDI client resources](https://github.com/eclipse-hawkbit/hawkbit-examples/tree/master/hawkbit-example-ddi-feign-client).
A small [simulator application](https://github.com/eclipse-hawkbit/hawkbit-examples/tree/master/hawkbit-example-mgmt-simulator) demonstrates how you can interact with the hawkBit via the [Management API
](http://www.eclipse.org/hawkbit/documentation/interfaces/management-api.html).
hawkBit provides REST interfaces
for [Management API](https://github.com/eclipse-hawkbit/hawkbit/tree/master/hawkbit-ddi-api)
and [DDI API](https://github.com/eclipse-hawkbit/hawkbit/tree/master/hawkbit-ddi-api). Using this interfaces you can
create a feign client with the help of
the [feign inheritance support](http://projects.spring.io/spring-cloud/spring-cloud.html#spring-cloud-feign-inheritance).
Our [example](https://github.com/eclipse-hawkbit/hawkbit-examples) modules demonstrate how to
create [Feign](https://github.com/Netflix/feign) client resources. Here you can find
the [Management API client resources](hhttps://github.com/eclipse-hawkbit/hawkbit-examples/tree/master/hawkbit-example-mgmt-feign-client)
and
the [DDI client resources](https://github.com/eclipse-hawkbit/hawkbit-examples/tree/master/hawkbit-example-ddi-feign-client).
A
small [simulator application](https://github.com/eclipse-hawkbit/hawkbit-examples/tree/master/hawkbit-example-mgmt-simulator)
demonstrates how you can interact with the hawkBit via the [Management API
](http://www.eclipse.org/hawkbit/documentation/interfaces/management-api.html).
## Example Management API simulator
In the follow code section, you can a see a feign client resource example. The interface extend the origin api interface to declare the `@FeignClient`. The `@FeignClient`declares that a REST client with that interface should be created.
In the follow code section, you can a see a feign client resource example. The interface extend the origin api interface
to declare the `@FeignClient`. The `@FeignClient`declares that a REST client with that interface should be created.
```Java
@FeignClient(url = "${hawkbit.url:localhost:8080}/" + MgmtRestConstants.TARGET_V1_REQUEST_MAPPING)
@@ -40,7 +53,8 @@ public class CreateStartedRolloutExample {
```
At [hawkbit-example-core-feign-client](https://github.com/eclipse-hawkbit/hawkbit-examples/tree/master/hawkbit-example-core-feign-client) is a spring configuration to auto configure some beans, which can be reused for a own feign client.
At [hawkbit-example-core-feign-client](https://github.com/eclipse-hawkbit/hawkbit-examples/tree/master/hawkbit-example-core-feign-client)
is a spring configuration to auto configure some beans, which can be reused for a own feign client.
```Java
@Configuration

27
site/content/guides/runhawkbit.md
View File

@@ -4,12 +4,14 @@ parent: Guides
weight: 31
---
In this guide we describe how to run a full featured hawkBit setup based on a production ready infrastructure. It is based on the hawkBit example modules and update server.
In this guide we describe how to run a full featured hawkBit setup based on a production ready infrastructure. It is
based on the hawkBit example modules and update server.
<!--more-->
{{% note %}}
The update server can in fact be run stand alone. However, only with an embedded H2, no Device Management Federation API and no artifact storage.
The update server can in fact be run stand alone. However, only with an embedded H2, no Device Management Federation API
and no artifact storage.
{{% /note %}}
## System Architecture
@@ -30,7 +32,8 @@ This guide describes a target architecture that is more like one that you will e
## Adapt hawkBit Update Server and Device Simulator to your environment.
As mentioned you can create your own application with hawkBit inside or adapt the existing example app. The second option will be shown here.
As mentioned you can create your own application with hawkBit inside or adapt the existing example app. The second
option will be shown here.
### Set MariaDB dependency to compile in the [update server POM](https://github.com/eclipse-hawkbit/hawkbit/blob/master/hawkbit-runtime/hawkbit-update-server/pom.xml)
@@ -44,7 +47,8 @@ As mentioned you can create your own application with hawkBit inside or adapt th
### Configure MariaDB/MySQL connection settings.
For this you can either edit the existing _application.properties_ or create a [new profile](http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-external-config-profile-specific-properties).
For this you can either edit the existing _application.properties_ or create
a [new profile](http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-external-config-profile-specific-properties).
```properties
spring.jpa.database=MYSQL
@@ -54,12 +58,15 @@ spring.datasource.password=YOUR_PWD
spring.datasource.driverClassName=org.mariadb.jdbc.Driver
```
Note: On Ubuntu 18.04 with MariaDB 10.1 installed from the default repository via apt install _COLLATE option_ of database have to be changed manually to "latin1".
For recent versions of MariaDB running on Ubuntu this is not required (cf. [system variables](https://mariadb.com/kb/en/differences-in-mariadb-in-debian-and-ubuntu), [issue](https://github.com/eclipse-hawkbit/hawkbit/issues/963))
Note: On Ubuntu 18.04 with MariaDB 10.1 installed from the default repository via apt install _COLLATE option_ of
database have to be changed manually to "latin1".
For recent versions of MariaDB running on Ubuntu this is not required (
cf. [system variables](https://mariadb.com/kb/en/differences-in-mariadb-in-debian-and-ubuntu), [issue](https://github.com/eclipse-hawkbit/hawkbit/issues/963))
### Configure RabbitMQ connection settings for update server and device simulator (optional).
We provide already defaults that should work with a standard Rabbit installation. Otherwise configure the following in the `application.properties` of the two services:
We provide already defaults that should work with a standard Rabbit installation. Otherwise configure the following in
the `application.properties` of the two services:
```properties
spring.rabbitmq.username=guest
@@ -93,9 +100,11 @@ see [update server](https://github.com/eclipse-hawkbit/hawkbit/tree/master/hawkb
### Compile & Run example scenario [creation script](https://github.com/eclipse-hawkbit/hawkbit-examples/tree/master/hawkbit-example-mgmt-simulator) (optional)
This has to be done before the device simulator is started. hawkBit creates the mandatory tenant metadata with first login into either Management API (which is done by this client).
This has to be done before the device simulator is started. hawkBit creates the mandatory tenant metadata with first
login into either Management API (which is done by this client).
However, this is not done by _DMF_ which is in fact used by the device simulator, i.e. without calling _Management API_ first hawkBit would drop all _DMF_ messages as the tenant is unknown.
However, this is not done by _DMF_ which is in fact used by the device simulator, i.e. without calling _Management API_
first hawkBit would drop all _DMF_ messages as the tenant is unknown.
### Compile & Run device simulator (optional)

24
site/content/release-notes.md
View File

@@ -28,25 +28,24 @@ Extensions: [Tag](https://github.com/eclipse-hawkbit/hawkbit-extensions/releases
**Release Date:** Thursday, August 24, 2023 <br />
Hawkbit: [Tag](https://github.com/eclipse-hawkbit/hawkbit/releases/tag/0.3.0M9) /
[Release](https://github.com/eclipse-hawkbit/hawkbit/milestone/24) <br />
[Release](https://github.com/eclipse-hawkbit/hawkbit/milestone/24) <br />
Extensions: [Tag](https://github.com/eclipse-hawkbit/hawkbit-extensions/releases/tag/0.3.0M9)
## 0.3.0M8
**Release Date:** Friday, April 21, 2023 <br />
Hawkbit: [Tag](https://github.com/eclipse-hawkbit/hawkbit/releases/tag/0.3.0M8) /
[Release](https://github.com/eclipse-hawkbit/hawkbit/milestone/23) <br />
[Release](https://github.com/eclipse-hawkbit/hawkbit/milestone/23) <br />
Extensions: [Tag](https://github.com/eclipse-hawkbit/hawkbit-extensions/releases/tag/0.3.0M8) /
[Release](https://github.com/eclipse-hawkbit/hawkbit-extensions/milestone/2)
[Release](https://github.com/eclipse-hawkbit/hawkbit-extensions/milestone/2)
## 0.3.0M7
**Release Date:** Monday, February 15, 2021 <br />
Hawkbit: [Tag](https://github.com/eclipse-hawkbit/hawkbit/releases/tag/0.3.0M7) /
[Release](https://github.com/eclipse-hawkbit/hawkbit/milestone/22?closed=1) <br />
[Release](https://github.com/eclipse-hawkbit/hawkbit/milestone/22?closed=1) <br />
Extensions: [Tag](https://github.com/eclipse-hawkbit/hawkbit-extensions/releases/tag/0.3.0M7) /
[Release](https://github.com/eclipse-hawkbit/hawkbit-extensions/milestone/1?closed=1)
[Release](https://github.com/eclipse-hawkbit/hawkbit-extensions/milestone/1?closed=1)
## 0.3.0M6
@@ -114,20 +113,19 @@ Extensions: [Tag](https://github.com/eclipse-hawkbit/hawkbit-extensions/releases
[Tag](https://github.com/eclipse-hawkbit/hawkbit/releases/tag/0.2.1) /
[Release](https://github.com/eclipse-hawkbit/hawkbit/milestone/9?closed=1)
## 0.2.0
First Eclipse hawkBit release including:
* **Core features:**
* Device and Software Repository
* Artifact Content Delivery
* Rollout/Campaign Management
* Device and Software Repository
* Artifact Content Delivery
* Rollout/Campaign Management
* **Interfaces:**
* Management API
* Direct Device Integration (DDI) API
* Device Management Federation (DMF) API
* Management API
* Direct Device Integration (DDI) API
* Device Management Federation (DMF) API
**Release Date:** Friday, June 15, 2018 <br />
[Tag](https://github.com/eclipse-hawkbit/hawkbit/releases/tag/0.2.0) /

67
site/content/whatishawkbit.md
View File

@@ -2,37 +2,73 @@
title: What is hawkBit?
weight: 10
---
Eclipse hawkBit&trade; is a domain-independent back-end framework for rolling out software updates to constrained edge devices as well as more powerful controllers and gateways connected to IP based networking infrastructure.
Eclipse hawkBit&trade; is a domain-independent back-end framework for rolling out software updates to constrained edge
devices as well as more powerful controllers and gateways connected to IP based networking infrastructure.
![](../images/hawkbit_logo.png)
## Why Software Updates in IoT?
Having software update capabilities ensures a secure IoT by means that it gives IoT projects a fighting chance against pandora's box that they opened the moment their devices got connected. From that moment on devices are at the forefront of IT security threats many embedded software developers historically never had to face. Shipping for instance a Linux powered device connected to the Internet without any security updates ever applied during its lifetime is kind of a suicidal act these days.
A more charming argument for software update is that it enables agile development for hardware and hardware near development. Concepts like a minimum viable product can be applied for devices as not all features need to be ready at manufacturing time. Changes on the cloud side of the IoT project can be applied to the devices at runtime as well.
Having software update capabilities ensures a secure IoT by means that it gives IoT projects a fighting chance against
pandora's box that they opened the moment their devices got connected. From that moment on devices are at the forefront
of IT security threats many embedded software developers historically never had to face. Shipping for instance a Linux
powered device connected to the Internet without any security updates ever applied during its lifetime is kind of a
suicidal act these days.
Sometimes Software Update is a business model on its own as it makes devices much more attractive to the customer if they are updatable, i.e. they do not only buy a product because of its current feature set but make also a bet on its future capabilities. In addition new revenue streams may arise from the fact that feature extensions can potentially be monetized (e.g. Apps) without the need to design, manufacture and ship a new device (revision).
A more charming argument for software update is that it enables agile development for hardware and hardware near
development. Concepts like a minimum viable product can be applied for devices as not all features need to be ready at
manufacturing time. Changes on the cloud side of the IoT project can be applied to the devices at runtime as well.
Sometimes Software Update is a business model on its own as it makes devices much more attractive to the customer if
they are updatable, i.e. they do not only buy a product because of its current feature set but make also a bet on its
future capabilities. In addition new revenue streams may arise from the fact that feature extensions can potentially be
monetized (e.g. Apps) without the need to design, manufacture and ship a new device (revision).
## Why hawkBit?
**Updating software** (components) on constrained edge devices as well as more powerful controllers and gateways is as mentioned before a **common requirement** in most IoT scenarios.
**Updating software** (components) on constrained edge devices as well as more powerful controllers and gateways is as
mentioned before a **common requirement** in most IoT scenarios.
At the time being, this process is **usually handled by the IoT solution itself**, sometimes backed by a full fledged device management system. We believe that this approach generates unnecessary **duplicate work** in the IoT space, in particular when considering the challenges of implementing a safe and reliable remote software update process: the software update process must never fail and also must never be compromised as, at the one hand, it can be used to fix almost any issue/problem on the device but at the same time also poses the greatest security threat if mis-used to introduce malicious code to the device.
At the time being, this process is **usually handled by the IoT solution itself**, sometimes backed by a full fledged
device management system. We believe that this approach generates unnecessary **duplicate work** in the IoT space, in
particular when considering the challenges of implementing a safe and reliable remote software update process: the
software update process must never fail and also must never be compromised as, at the one hand, it can be used to fix
almost any issue/problem on the device but at the same time also poses the greatest security threat if mis-used to
introduce malicious code to the device.
In addition we believe the software update process to be relatively **independent from particular application domains** when seen from the back-end (cloud) perspective. Updating the software for an entire car may differ from updating the firmware of a single sensor with regard to the connectivity of the device to the cloud and also to the complexity of the software package update process on the device. However, the process of rolling out the software, e.g. uploading an artifact to the repository, assigning it to eligible devices, managing the roll out campaign for a large number of devices, orchestrating content delivery networks to distribute the package, monitoring and reporting the progress of the roll-out and last but not least requirements regarding security and reliability are quite similar.
In addition we believe the software update process to be relatively **independent from particular application domains**
when seen from the back-end (cloud) perspective. Updating the software for an entire car may differ from updating the
firmware of a single sensor with regard to the connectivity of the device to the cloud and also to the complexity of the
software package update process on the device. However, the process of rolling out the software, e.g. uploading an
artifact to the repository, assigning it to eligible devices, managing the roll out campaign for a large number of
devices, orchestrating content delivery networks to distribute the package, monitoring and reporting the progress of the
roll-out and last but not least requirements regarding security and reliability are quite similar.
Software update itself is often seen as a sub process of general device management. In fact, most device management systems include functionality for triggering groups of devices to perform an update, usually accompanied by an artifact repository and basic reporting and monitoring capabilities. This is true for both systems specifically targeting IoT as well as systems originating from the mobile area.
Software update itself is often seen as a sub process of general device management. In fact, most device management
systems include functionality for triggering groups of devices to perform an update, usually accompanied by an artifact
repository and basic reporting and monitoring capabilities. This is true for both systems specifically targeting IoT as
well as systems originating from the mobile area.
Existing **device management systems** usually **lack** the capability to **efficiently organize roll outs at IoT scale**, e.g. splitting the roll out into sub groups, cascading them, automatically stopping the roll out after a defined error threshold etc. They are also usually restricted to a single device management protocol, either a proprietary one or one of the existing standard protocols like LWM2M, OMA-DM or TR-069. Even if they support more than one such protocol, they are often a result of the device management protocol they started with and restricted in their adoption capabilities to others.
Existing **device management systems** usually **lack** the capability to **efficiently organize roll outs at IoT scale
**, e.g. splitting the roll out into sub groups, cascading them, automatically stopping the roll out after a defined
error threshold etc. They are also usually restricted to a single device management protocol, either a proprietary one
or one of the existing standard protocols like LWM2M, OMA-DM or TR-069. Even if they support more than one such
protocol, they are often a result of the device management protocol they started with and restricted in their adoption
capabilities to others.
At the same time the wide functional scope of a full fledged **device management system introduces unnecessary (and unwanted) complexity** to many IoT projects. This is particularly true for IoT solutions working with constrained devices where requirements regarding generic device management are often very limited only but a secure & reliable software update process is still mandatory.
At the same time the wide functional scope of a full fledged **device management system introduces unnecessary (and
unwanted) complexity** to many IoT projects. This is particularly true for IoT solutions working with constrained
devices where requirements regarding generic device management are often very limited only but a secure & reliable
software update process is still mandatory.
As a result we have the need for a domain independent solution
* that works for the majority of IoT projects
* that goes beyond the pure update and handles more complex **roll out strategies** needed by large scale IoT projects.
* that at the same time is **focused on software updates** in the IoT space
* and that is able to work on its own for simple scenarios while having the capability to integrate with existing device management systems and protocols.
* that works for the majority of IoT projects
* that goes beyond the pure update and handles more complex **roll out strategies** needed by large scale IoT projects.
* that at the same time is **focused on software updates** in the IoT space
* and that is able to work on its own for simple scenarios while having the capability to integrate with existing device
management systems and protocols.
## Cloud Ready
@@ -40,4 +76,5 @@ As a result we have the need for a domain independent solution
* **Functional Scalability**: rollouts with hundreds of thousands of individual devices in it.
* **Reliability**: software update as the last line of defense against device faults and vulnerabilities.
* **Managed device complexity**: device topologies inside each individual provisioning target.
* **Integration flexibility**: connect and integrate through various (non-)standardized device management protocols directly or through federated device managements.
* **Integration flexibility**: connect and integrate through various (non-)standardized device management protocols
directly or through federated device managements.