Status of "distributed board access"

[aparcar]

Hi, I'm currently evaluating labgridas a tool for OpenWrt development where people could share their local hardware with other developers around the world.

Background: OpenWrt supports some thousands of devices which are impossible to own by reviewers, a better approach could be to have a community sharing whatever device they have via labgrid.

If possible I'd setup a low-cost setup guide to deploy a DUT and labgrid-exporter with a public crossbar instance. Developers and community could connect to the database and test changes.

For that a few questions:

• Is a setup like that within the scope of labgrid?
• Is it possible to have device definitions centrally managed so not everyone can add devices randomly but needs approval by administrators. That includes places.
• Would labgrid scale to 100s or 1000s of devices?

[jluebbe]

There are some obstacles for this setup, mostly related to security.

Labgrid's design expects it to be run in a trusted environment, so there is not authentication for the communication with the coordinator. Everyone with access to the coordinator can currently configure places. Note that just because a place exists, it doesn't give anyone access to the corresponding resources.

Also, anyone who wants to use a place, usually needs SSH access to the corresponding exporter (no root access, though). So you can limit access to resources simply by using normal SSH access and unix permissions.

We currently have more than 100 places in our lab and so far the coordinator is not a bottleneck. As any resource changes are currently broadcasted to all clients, this might lead to overhead when you go to 1000s of devices.

[aparcar]

From my understanding it would be enough if a user can use labgrid-client shell to access the device, no need for "real" SSH to the parent device, right?

I see two roles in that case, one who can setup places and thereby add resources and one which can only consume those places. Ideally each user got their own credentials.

[jluebbe]

Currently, labgrid has not credentials of its own. Access is either restricted via network (firewalls) or allowed via SSH keys.

For the labgrid-client console (which I assume you meant) example, the user's machine must either be allowed to connect directly to the RFC2217 host:port (ser2net or serial service) or to open a SSH connection to the exporter which is then used to tunnel the console connection.

Early on, we made the decision to not handle authentication and permissions in labgrid itself, but to rely on existing tools (like SSH/unix users and network segmentation). That has worked well so far and avoided a lot of complexity. So I'd like to first think about other options to solve you use-case before adding auth to labgrid itself.