Commit 619ca8b2a8 changed the ccimx6ul's default endpoint URL and client cert
path in order to prevent performance issues if the client cert is erased before
registering the device.
In reality, the client cert path doesn't really matter after this change since
the remotemanager.digi.com endpoint won't make use of it, and we now ensure
that /mnt/data is writable; so we might as well keep using that path.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
If a target's DRM certificate is lost/erased before registering said target,
the CCCS server will reject all connection attempts from the target. This
can happen during development, as our installer scripts format the data
partition where the certificate is stored by default (see commit c17af3fd47).
Since the ccimx6ul uses sysvinit, we respawn the cccsd daemon via inittab if
process ends unexpectedly (see commit b154154a7e). When the server always
rejects connections due to a missing certificate, the cccsd daemon is
constantly respawning and terminating prematurely. Said daemon is very
CPU-intensive during initialization, so this causes the overall system's
performance to be hindered.
For now, to avoid this situation, use the CCCS endpoint that doesn't require
a certificate in order to ensure stable connections even if the data partition
gets formatted.
https://onedigi.atlassian.net/browse/DEL-9892https://onedigi.atlassian.net/browse/DEL-9894
This reverts commit 4f8ed2d434.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Until DEY 5.0, the ccimx6ul platform was the only one that did not include a
`data` partition.
As a result, `cccsd` had to store the client certificate from Remote Manager in
the root filesystem, under `/etc/ssl/certs` by default.
This setup caused issues after a software update, as the received client
certificate would be lost, making the device unable to reconnect to the server
until the certificate was manually reset from Remote Manager.
The same problem occurred in dual-boot systems, since the certificate was stored
in the rootfs of the current bank and was not accessible from the other bank.
To avoid this situation, the ccimx6ul used the `remotemanager.digi.com` endpoint
instead of `edp12.devicecloud.com`, as the former does not support or deliver
client certificates.
Now that DEY 5.0 includes a `data` partition in the ccimx6ul partition table, we
can remove this exception and allow the use of `edp12.devicecloud.com`, storing
the certificates persistently in the `data` partition.
Signed-off-by: Tatiana Leon <Tatiana.Leon@digi.com>
Due to a change in systemd the default home directory is now "/root".
Modify our recipes to match with this change.
Signed-off-by: Francisco Gil <francisco.gilmartinez@digi.com>
The package name has changed due to commit 52287bf6be.
This fix makes use of the Yocto variable `REMOVE_POSTINST_RPN`,
which holds the target name for the `remove-pkg-postinst-ontarget`
class.
Signed-off-by: Francisco Gil <francisco.gilmartinez@digi.com>
Some parameters of the CCCS configuration file need to be substituted
at run-time during a postinst script. Such script takes actions depending
on the value of U-Boot env variables.
The libubootenv recipe itself also has a postinst script that modifies
the U-Boot env configuration file (on NAND-based platforms).
If there are no dependencies between these two recipes, poky will decide
the order in which the postinst scripts are named (and thus executed)
during the first boot.
By creating the rdepends to libubootenv, we guarantee that its postinst
script is run before the cccs one, which depends on the environment being
accessible.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://onedigi.atlassian.net/browse/DEL-9282
If 'CCCS_CONF_PATH' is defined, the specified file is installed as CCCS
configuration file without any modification.
It it is not defined or it is empty, the configuration file in cc_dey
('cc_dey/cccs-daemon/cfg_files/cccs.conf') is installed and modified if
required.
Signed-off-by: Tatiana Leon <Tatiana.Leon@digi.com>
To work in a dualboot memory layout out of the box, the most
common use case of the firmware update through the cloud should
be on the fly because in nand platforms there is not enough
memory to keep the update file in the system.
https://onedigi.atlassian.net/browse/DEL-8305
Signed-off-by: Francisco Gil <francisco.gilmartinez@digi.com>
This recipe generates several packages:
* 'cccs' includes the CCCS shared library
* 'cccs-daemon' includes the binary and resources to execute the CCCS daemon
(daemon, service and init scripts, configuration file)
* 'cccs-cert' includes the required certificate to use CCCS daemon
* 'cccs-gs-demo' includes the binary and resources to execute the CCCS get
started demo (binary, service and init scripts)
* 'cccs-legacy' includes the binary (all-in-one) application to execute
the legacy CCCS application (aka cloud-connector) and the configuration
file
* 'cccs-legacy-dev' includes resources to develop legacy CCCS applications
(all-in-one) (header files inside 'cloud-connector' and 'cloudconnector.pc'
pkg config file)
* 'cccs-legacy-staticdev' includes static resources to develop legacy CCCS
applications (all-in-one) (static library)
This commit also renames:
* 'CLOUDCONNECTOR_PKGS' variable to 'CCCS_PKGS'.
* 'CC_DEVICE_TYPE' variable to 'CCCS_DEVICE_TYPE'.
https://onedigi.atlassian.net/browse/DEL-8628
Signed-off-by: Tatiana Leon <Tatiana.Leon@digi.com>
Arturo Buzarra
Gabriel Valcazar
Tatiana Leon
Francisco Gil
Javier Viguera
Hector Palacios