Allow NetworkService to be used without an explicit SSH username

[ozan956]

Allow NetworkService to be used without an explicit SSH username.

Until now, NetworkService.username was required and SSHDriver always passed
it through to ssh, scp, etc. That prevented setups where the SSH user should
come from the local SSH configuration or the default SSH user resolution.

This change makes NetworkService.username optional and updates SSHDriver to
only pass -l <username> or user@host when a username is explicitly set.

The client-side fallback path in labgrid.remote.client also no longer forces
username="root". While adding regression coverage for that path, this also
surfaced that the fallback resource creation needs name=None, which is now
passed explicitly.

I verified the change with some tests called test_run_no_username, test_put_get_no_username and test_get_ssh_no_username for the no-username paths.

Checklist

• Documentation for the feature
• Tests for the feature
• PR has been tested

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 61.1%. Comparing base (fb48582) to head (579db71).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff            @@
##           master   #1863     +/-   ##
========================================
+ Coverage    61.0%   61.1%   +0.1%     
========================================
  Files         182     182             
  Lines       14882   14903     +21     
========================================
+ Hits         9083    9118     +35     
+ Misses       5799    5785     -14     

Flag	Coverage Δ
3.10	61.1% <100.0%> (+0.1%)	⬆️
3.11	61.1% <100.0%> (+0.1%)	⬆️
3.12	61.1% <100.0%> (+0.1%)	⬆️
3.13	61.1% <100.0%> (+0.1%)	⬆️
3.14	61.1% <100.0%> (+0.1%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

[Emantor]

This is going to be a breaking change for the remote infrastructure, older labgrid will expect the now optional username parameter. IMO we should still use None instead of "" which works around that.

[ozan956]

This is going to be a breaking change for the remote infrastructure, older labgrid will expect the now optional username parameter. IMO we should still use None instead of "" which works around that.

Thanks for the review! I resolved them all now. Sorry for late response.

[jluebbe]

We use NetworkService for SSH daemons on the target. What would be the use-case for having the username depend on client side configuration? I'd normally prefer to have test suites behave identically for different users.

[ozan956]

We use NetworkService for SSH daemons on the target. What would be the use-case for having the username depend on client side configuration? I'd normally prefer to have test suites behave identically for different users.

That is a fair point. For a NetworkService declared in a test environment, I agree that the username should normally be explicit so that test suites behave identically for different users.

My use case is shared lab usage rather than making test suites depend on client-side configuration. Several users consume the same environment for ad-hoc ssh/scp operations, and using one fixed Unix account forces them to share the same remote home directory. This can lead to interference between users.

Making the username optional allows this shared environment to leave account selection to each user's SSH configuration. Explicitly configured usernames continue to behave exactly as before.

Also with #1889, we are going to sharing the envs remotely. So not having a username there would be better I guess. Users gonna anyways having ssh configs at their end.

[jluebbe]

So in your case, each developer/lab user has their own user account on the target/device-under-test?

[ozan956]

So in your case, each developer/lab user has their own user account on the target/device-under-test?

Now we are using a shared user, especially since the ci is the main consumer of it. But once many more people start to use the boards, we cannot control what these all consumers doing with all those available commands. And something like this can happen: user#1 sends u-boot binares to home directory, working on board#1. at the same time user#2 sends their binaries to same home directory for board#2. So they going to be overriden. Since we dont wanna "lock' the directories, I believe the easiest thing is to seperate users.

I am open to any other suggestions to get rid of that race condition as well.