[1/1] package/qbee-agent: new package

This patch add qbee-agent, an open source device management software
for Linux devices.

Signed-off-by: Jon Henrik Bjørnstad <jonhenrik@qbee.io>
---
 DEVELOPERS                         |  3 +++
 package/Config.in                  |  1 +
 package/qbee-agent/Config.in       | 18 ++++++++++++++
 package/qbee-agent/qbee-agent.hash |  3 +++
 package/qbee-agent/qbee-agent.mk   | 39 ++++++++++++++++++++++++++++++
 5 files changed, 64 insertions(+)
 create mode 100644 package/qbee-agent/Config.in
 create mode 100644 package/qbee-agent/qbee-agent.hash
 create mode 100644 package/qbee-agent/qbee-agent.mk

Jon, All,

On 2023-11-10 11:45 +0100, Jon Henrik Bjørnstad via buildroot spake thusly:
> This patch add qbee-agent, an open source device management software
> for Linux devices.
> 
> Signed-off-by: Jon Henrik Bjørnstad <jonhenrik@qbee.io>
> ---
[--SNIP--]
> diff --git a/package/qbee-agent/Config.in b/package/qbee-agent/Config.in
> new file mode 100644
> index 0000000000..c35eabff91
> --- /dev/null
> +++ b/package/qbee-agent/Config.in
> @@ -0,0 +1,18 @@
> +config BR2_PACKAGE_QBEE_AGENT
> +	bool "qbee-agent"
> +	depends on BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS
> +	select BR2_PACKAGE_OPENSSH if !BR2_PACKAGE_DROPBEAR_CLIENT # runtime
> +	select BR2_PACKAGE_IPTABLES # runtime
> +	select BR2_PACKAGE_BUSYBOX_SHOW_OTHERS # runtime
> +	select BR2_PACKAGE_SHADOW # runtime
> +	select BR2_PACKAGE_BASH # runtime
> +	help
> +	  Qbee is a device management platform that comprise
> +	  of an open-source agent and a hosted SaaS backend.

Is there a public implementation for that backend?

> +	  This config installs pre-built static binaries made

That is no longer the case. ;-)

> +	  with the official public signing key for qbee.io. The
> +	  binaries will work seamlessly with the qbee.io device
> +	  management backend.

See below for that key...

[--SNIP--]
> diff --git a/package/qbee-agent/qbee-agent.mk b/package/qbee-agent/qbee-agent.mk
> new file mode 100644
> index 0000000000..f568372e01
> --- /dev/null
> +++ b/package/qbee-agent/qbee-agent.mk
> @@ -0,0 +1,39 @@
> +################################################################################
> +#
> +# qbee-agent package
> +#
> +################################################################################
> +
> +QBEE_AGENT_VERSION = 2023.44
> +QBEE_AGENT_SITE = $(call github,qbee-io,qbee-agent,$(QBEE_AGENT_VERSION))
> +QBEE_AGENT_LICENSE = Apache-2.0
> +QBEE_AGENT_LICENSE_FILES = LICENSE
> +
> +QBEE_AGENT_COMMIT_ID = 582900356222860bfc40567ea359941c9d34f499

Why is the commit hash important? How can we ensure that, in a future
version bump in QBEE_AGENT_VERSION, we ensure the commit hash is
updated? Can we use the _VERSION instead of the hash?

As far as I can see, it is only used to set app.Commit, which in turn is
only used to display that to the user, in addition to the version
string. So, that does not seem very important, and re-using _VERSION
looks like it would be OK, as it is a tag.

> +QBEE_AGENT_PUBLIC_SIGNING_KEY = z5mUFaW-3t3WRIjkUr2dVOzPgGw3oyR-tzBlInGfz44.EJExLiJex1X7nT7p6XTxO8kjmGkv6ik60XMzvMe-87g

What is this key valid for?

I can see that it is different from the one on github:

    https://github.com/qbee-io/qbee-agent/blob/main/Makefile#L10

    PUBLIC_SIGNING_KEY=xSHbUBG7LTuNfXd3zod4EX8_Es8FTCINgrjvx1WXFE4.plCHzlDAeb3IWW1wK6P6paMRYO4f8qceV3lrNCqNpWo

Can we extract the key from the Makefile rather than have our own here?

Also, the comment just above that key states "For production release, it
must be replaced with the correct public key". How can this be achieved
in the context of Buildroot? Or is the one you provided the actual
production public key?

My previous suggestion was to give the user the option to provide their
own key. Why can't we do that?

> +QBEE_AGENT_LDFLAGS = -s -w \
> +	-X github.com/qbee-io/qbee-agent/app.Version=$(QBEE_AGENT_VERSION) \
> +	-X github.com/qbee-io/qbee-agent/app.Commit=$(QBEE_AGENT_COMMIT_ID) \
> +	-X github.com/qbee-io/qbee-agent/app/binary.PublicSigningKey=$(QBEE_AGENT_PUBLIC_SIGNING_KEY)
> +
> +define QBEE_AGENT_INSTALL_TARGET_CMDS
> +	$(INSTALL) -m 0755 $(@D)/bin/qbee-agent $(TARGET_DIR)/usr/bin/qbee-agent

That part shoud not be necessary, as this is the default of the
golang-package infra [0]; you just need to install the .cert as a
post-install hook:

    define QBEE_AGENT_INSTALL_CERT
        $(INSTALL) -D -m 0600 $(@D)/package/share/ssl/ca.cert $(TARGET_DIR)/etc/qbee/ppkeys/ca.cert
    endef
    QBEE_AGENT_POST_TARGET_INSTALL_HOOKS += QBEE_AGENT_INSTALL_CERT

[0] https://buildroot.org/downloads/manual/manual.html#_infrastructure_for_go_packages

> +	$(INSTALL) -D -m 0600 $(@D)/package/share/ssl/ca.cert $(TARGET_DIR)/etc/qbee/ppkeys/ca.cert
> +endef
> +
> +define QBEE_AGENT_INSTALL_INIT_SYSTEMD
> +	$(INSTALL) -D -m 0644 $(@D)/package/init-scripts/systemd/qbee-agent.service \
> +		$(TARGET_DIR)/usr/lib/systemd/system/qbee-agent.service
> +endef
> +
> +define QBEE_AGENT_INSTALL_INIT_SYSV
> +	$(INSTALL) -D -m 755 $(@D)/package/init-scripts/sysvinit/qbee-agent \
> +		$(TARGET_DIR)/etc/init.d/S99qbee-agent
> +endef
> +
> +define QBEE_AGENT_LINUX_CONFIG_FIXUPS
> +	$(call KCONFIG_ENABLE_OPT,CONFIG_TUN)
> +endef

Why is TUN needed inthe kernel?

Do not hesitate to explain things in the commit log, even if they look
trivial to you ; even just a little sentence is OK (e.g. totally made-up
justification: "TUN is needed beacuse qbee-agent creates a vpn-like
tunnel to the server and routes all the communications through that
tunnel").

So, now I think the package is quite OK as per the Buildroot coding
rules 👍, with only vert minor thins (comment in Config.in, dropping
_COMMIT_HASH, commit log with a bit more explanations).

The rest of the questions mostly revolve around the key, and how we can
manage that.

Regards,
Yann E. MORIN.

> +$(eval $(golang-package))
> -- 
> 2.25.1
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

Hi all,


On Fri, Nov 10, 2023, 2:45 AM Jon Henrik Bjørnstad <jonhenrik@qbee.io>
wrote:

> This patch add qbee-agent, an open source device management software
> for Linux devices.
>

Are there any buildroot users today who would want to install this package
with it's proprietary backend independently of using the proprietary
backend?

Who holds the private key for that public key and what can they then do
with my device if I chose to install this package?

This seems like a case where, if I was adding this package for a
proprietary service, I would instead opt to use a Buildroot External
Package for the reasons stated above:

https://buildroot.org/downloads/manual/customize-outside-br.txt

Indeed: there are many cases like this one where I'll maintain an external
buildroot extensions tree because the packages are not fully open source
(backend and frontend) and therefore probably not of interest to the main
buildroot user base.

For a counter example to this see Mender and Balena Engine.

Thanks,
Christian Stewart

On 10/11/2023 18:14, Christian Stewart via buildroot wrote:
> Hi all,
> 
> 
> On Fri, Nov 10, 2023, 2:45 AM Jon Henrik Bjørnstad <jonhenrik@qbee.io 
> <mailto:jonhenrik@qbee.io>> wrote:
> 
>     This patch add qbee-agent, an open source device management software
>     for Linux devices.
> 
> 
> Are there any buildroot users today who would want to install this package with 
> it's proprietary backend independently of using the proprietary backend?
> 
> Who holds the private key for that public key and what can they then do with my 
> device if I chose to install this package?
> 
> This seems like a case where, if I was adding this package for a proprietary 
> service, I would instead opt to use a Buildroot External Package for the reasons 
> stated above:
> 
> https://buildroot.org/downloads/manual/customize-outside-br.txt 
> <https://buildroot.org/downloads/manual/customize-outside-br.txt>
> 
> Indeed: there are many cases like this one where I'll maintain an external 
> buildroot extensions tree because the packages are not fully open source 
> (backend and frontend) and therefore probably not of interest to the main 
> buildroot user base.

  I don't think "open source agent for a closed-source backend" means that we 
don't want to carry it in buildroot. In fact, we have at least one of those 
already: azure-iot-sdk-c. I'm sure there are others.


  Regards,
  Arnout

> 
> For a counter example to this see Mender and Balena Engine.
> 
> Thanks,
> Christian Stewart
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

Arnout, Christian, Jon, All,

On 2023-11-10 20:28 +0100, Arnout Vandecappelle via buildroot spake thusly:
> On 10/11/2023 18:14, Christian Stewart via buildroot wrote:
> >On Fri, Nov 10, 2023, 2:45 AM Jon Henrik Bjørnstad <jonhenrik@qbee.io
> ><mailto:jonhenrik@qbee.io>> wrote:
> >    This patch add qbee-agent, an open source device management software
> >    for Linux devices.
> >Are there any buildroot users today who would want to install this package
> >with it's proprietary backend independently of using the proprietary
> >backend?
> >
> >Who holds the private key for that public key and what can they then do
> >with my device if I chose to install this package?

Those are valid questions, but they are to the user who builds a rootfs
with qbee-agent to assess. If they _need_ qbee-agent (for whatever
reason, good or bad), then it is available in Buildroot.

As Yann@work pointed out however, is that we need to have a little
explanation on what the key is, and whether users may need to have their
own, and why the key provided in this patch differs from the one in the
github repo, and what the comment in the github repo is about.

> >This seems like a case where, if I was adding this package for a
> >proprietary service, I would instead opt to use a Buildroot External
> >Package for the reasons stated above:
> >https://buildroot.org/downloads/manual/customize-outside-br.txt
> ><https://buildroot.org/downloads/manual/customize-outside-br.txt>

Not really. br2-external trees are made for packages one does not want
to be public, i.e. the packages themselves are internal to one's org.

> >Indeed: there are many cases like this one where I'll maintain an external
> >buildroot extensions tree because the packages are not fully open source
> >(backend and frontend) and therefore probably not of interest to the main
> >buildroot user base.
>  I don't think "open source agent for a closed-source backend" means that we
> don't want to carry it in buildroot. In fact, we have at least one of those
> already: azure-iot-sdk-c. I'm sure there are others.

The point I was about to make.

It would be a bit sad indeed to not have a open source implementation fo
the server side, or that users can't specify an alternate provider (i.e.
choose to run their own), but that's orthogonal to having the client in
Buildroot.

Regards,
Yann E. MORIN.