cesarbr / knot-gateway-buildroot Goto Github PK

Add the minimal requirements for contributors to know how to format commit messages, break PRs into small commits, etc.

As an example of things to clarify:

• I've noticed that we changed from the BR format of showing where the changes were done. The mainline uses <dir>/<subdir>, we're using <dir>: <dir> (most of the times, at least).

The investigation of problems that appears on the gateway isn't an easy task since there are a lot of services integrated into it. The most common approach is checking the system log (by looking at the /var/log/messages file) and checking the service's logs individually by restarting them and sometimes changing their log configuration properties manually. Hence, despite having documentation describing each of these steps, it requires a certain level of technical knowledge causing this process to be almost impossible for new users.

Therefore, one solution to this could be creating a tool that generates a diagnostic report by looking for the service's logs and collecting other system's properties that can indicate the problem source.

When a new package (redis) was added to the system, it has created a linux user with the same uid used for the "knot" user. This made some processes that executed as 'knot' user to fail.

Setup

Steps to reproduce

1. Run make menuconfig and select a package that create a new user (e.g. redis);
2. Build the linux image;
3. flash the SD card.

Expected result

All KNoT processes must be running as "knot" user.

Actual result

The webui and knot-fog aren't being started. Besides, the knotd and nrfd processes are running as "redis" user.

Possible solution

Instead of using a fixed value for the "knot" uid, it should be defined dynamically.

As a developer, I'd like to expose my local IP and Port through multicast DNS allowing mobile clients to easily fetch the route to access the web UI backend to make requests about connected things or Open Thread configuration.

As a platform developer, I want to have the necessary documentation so that I can develop the services that will compose the edge/fog infrastructure.

DoD:

• Investigate the similar services of the main IoT platforms
• Design initial architecture
• Create spec components

The MongoDB is currently unprotected. In this way, if you access the mongo shell in your host machine using just the raspberry IP, you can operate on it and drop a database.

$ mongo <raspberry_ip>/knot_web
> db.dropDatabase()
> use knot_fog
> db.dropDatabase()

To solve this issue we need to follow the MongoDB Security Checklist, specially to enable the minimal security configuration: authentication and access control mechanisms.

As a product owner, I'd like to have a Buildroot img available for Geniatech Gateway based on KNoT BR implementation.

As a platform developer, I want to have the users service integrated into the Buildroot.

• Add package to BR

At the moment, KNoT is over 2018.08, which is from on Sep 6, 2018.
Is it still the idea to keep up to date with BR official repository?

Estou com problemas para criar a imagem do gateway. Fiz o processo descrito no arquivo instructions_to_build_gateway_image.txt (do zip knot_v01.00), alterando a linha BR2_GATEWAY_HARDWARE=configs/raspberrypi2_defconfig make knot_gateway para BR2_GATEWAY_HARDWARE=configs/raspberrypi3_defconfig make knot_gateway e fiz o make.

Depois desse processo, fiz o passo 4) do arquivo para executar o script create_boot_disk.sh. As ultimas linhas da execução desse script recebi o seguinte output.

Copying bootloader files...
dd: falhou em abrir 'output/images/boot.vfat': Arquivo ou diretório não encontrado
Copying root filesystem...
dd: falhou em abrir 'output/images/rootfs.ext4': Arquivo ou diretório não encontrado
resize2fs 1.42.13 (17-May-2015)
resize2fs: Bad magic number in super-block tentando abrir /dev/sdb2
Não se pôde encontrar superbloco de sistema válido.
Done!
Please remove the sdcard and boot the board.

Consequentemente, não consegui dar boot no cartão. Alguma sugestão?

When trying to run a service that requires a non-privileged user to run it I notice the user was created with root permissions. In order to show the bug, I logged in as a 'knot' user and printed its UID.

ITAGI-10737:knot-fog-connector jneto$ ssh [email protected]
[email protected]'s password:
# who
knot            pts/0           00:00   Oct  3 12:29:29  192.188.188.4
# whoami
root
# id -u
0

As a developer, I'd like to expose OT settings through multicast DNS allowing mobile clients to fetch easily gateway's OT settings. If the gateway has been configured previously, the broadcasted information can be read as soon as the Mobile connects to the same sub-network of the gateways. The read information will be pushed to new devices (Things) using BLE.

Broadcasting OT settings is a security breach acceptable at this point considering that it provides better usability at the setup process.

Output:
All KNoT required packages dependencies issues on Buildroot checked and fixed.

It's expected that we have a minimal fog/edge infrastructure at the end of this epic. The main features will be defined in the investigations.

As of now, there are a lot of changes done in files and folders that are not supposed to be changed, such as the Makefile.
It's recommended by buildroot documentation that if we create a new board, we do it in a specific folder.
To avoid conflicts when rebasing with future BR versions, I suggest the creation of boards/knot/ to have our boards, for now only raspberrypi (raspberrypi3).

Make gateway run on Rpi Zero W

This is necessary because Rpi Zero is cheaper.

Output:
Updated and organized README file with instructions to build and flash KNoT Boards.

Add a mechanism to allow users to clear apps, network and system settings.

As a platform developer, I want to have the things service integrated into the Buildroot. Moreover, I also want to investigate security issues related to the thing's token.

• Add package to BR
• Define how the thing's token will be treated by the platform

As a platform developer, I want to have a well-defined AMQP API so that I can know which messages should the services send or expect for.

• Map operations to exchange and routing key names
• Define exchange types
• Create/Update documentation
• Define error messages