Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ManagedFile uses /var/cache/labgrid/.. sync path even when resource is remote #1398

Open
flxzt opened this issue May 8, 2024 · 5 comments
Open

Comments

@flxzt
Copy link

flxzt commented May 8, 2024

Currently the implementation of sync_to_resource() in managed file always uses the user cache directory (var/cache/labgrid/..), even when user of the class provides a remote resource, meaning the connection is actually not to the exporter, but to the target machine.

This works when the target user is root and able to create the /var/cache/labgrid/.. directory, but it might fail when they are not.

To fix this, the directory could maybe be /var/tmp or /tmp like it is done in other parts of the code ?

@flxzt flxzt changed the title ManagedFile uses var/cache/labgrid/.. sync path even when resource is remote ManagedFile uses /var/cache/labgrid/.. sync path even when resource is remote May 8, 2024
@Emantor
Copy link
Member

Emantor commented May 8, 2024

See contrib/systemd/tmpfiles.d/labgrid.conf for an example tmpfiles.d entry and the Attention box in the Gettings Started Exporter section.

@flxzt
Copy link
Author

flxzt commented May 8, 2024

Thanks for the answer. I am not talking about configuring the exporter though. It's possible to specify Network* resources with the host field set to something different than the exporter, i.e. the DUT. If I then want to use ManagedFile in a custom driver with this resource bound, it will assume it can create and write to the /var/cache/labgrid directory because it thinks it makes a connection to the exporter.

I guess I am using Network* resources or the ManagedFile class in a more general way that intended? I might also be slightly confused about the terminology, some resources are named Network*, some Remote*. Is this just a inconsistency or are there differences how they are supposed to be used?

@Emantor
Copy link
Member

Emantor commented May 8, 2024

The terminology is only an inconsistency as far as i can see. For dut file management the SSHDriver already implements the FileTransferProtocol with put()/get(). The ManagedFile is only meant for syncing files to the exporter for i.e. upload of bootloaders via the BootstrapProtocol.

@flxzt
Copy link
Author

flxzt commented May 8, 2024

The ManagedFile is only meant for syncing files to the exporter for i.e. upload of bootloaders via the BootstrapProtocol.

Ah okay, so I'll just bind to FileTransferProtocol with my custom driver then.

I guess it doesn't come up often, but this is then still an issue whenever a user defines a different host than the exporter in a resource where it's corresponding driver uses FileManager in its implementation

The docs also seem to be outdated. It does read like it originally was intended to be used in a more general way

@flxzt
Copy link
Author

flxzt commented May 8, 2024

On second thought I do think it would better to keep the drivers using Network* resources clear of exporter-specific implementation because it would make it easier to access IO from remote machines (not necessarily the DUT, but for example other developer machines in an ad-hoc way) with only a client and an environment config (and ssh access), without the exporter-coordinator infrastructure set up.

Could it be that this was the original architecture, but shifted either intentionally or unintentionally at some point?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants