Hi, I am trying to make use of environment variables defined on my lava-server inside interactive tests. I have had some success with this, but I am not sure why one method works over the other. For example, I do something like the following: echo 'wget --user=some-name --password=${SECRET_PASSWORD}' > somefile.sh
And that works just fine. But when I already have a script (say it exists on the DUT already) that just takes it as a parameter, it doesn't work. Example: some_script.sh -p ${SECRET_PASSWORD} -u some-name
I have also tried accessing it directly in the script, similar to what somefile.sh would look like on the inside, but had no success with that. I have tried exporting the environment variable as another one to see if that would work, but to no avail.
Is there something I'm missing? What I can I do to achieve this without hardcoding it anywhere in my scripts?
Regards, Michael
On Fri, May 9, 2025 at 4:33 AM Michael Peddie michael.peddie@gallagher.com wrote:
Hi, I am trying to make use of environment variables defined on my lava-server inside interactive tests.
tests run on the worker (dispatcher) not on a server unless it's the same machine. Could you share more details on how you define the variables?
I have had some success with this, but I am not sure why one method works over the other. For example, I do something like the following: echo 'wget --user=some-name --password=${SECRET_PASSWORD}' > somefile.sh
for downloading the easiest is to use artifact tokens that are defined in your user profile. This can be used in the download stage of deployment. It might not be what you're attempting, but I'm just pointing out it's there and it's very convenient:
- deploy: images: image: headers: Authentication: ARTIFACT_TOKEN url: http://example.com/my_file
And that works just fine. But when I already have a script (say it exists on the DUT already) that just takes it as a parameter, it doesn't work. Example: some_script.sh -p ${SECRET_PASSWORD} -u some-name
scripts in the test shell are executed in the context of the shell. Variables in this shell are defined in the job definition or test definition https://github.com/Linaro/test-definitions/blob/master/automated/linux/wlan-...
These parameters become env variables for the script that executes the test.
I have also tried accessing it directly in the script, similar to what somefile.sh would look like on the inside, but had no success with that. I have tried exporting the environment variable as another one to see if that would work, but to no avail.
Is there something I'm missing? What I can I do to achieve this without hardcoding it anywhere in my scripts?
I'm missing the detail how you define the variable. Please share that and we can try to figure out the solution.
Best Regards, Milosz
Hi Milosz,
I am defining the variable in the env.yaml found in /etc/lava-server on the lava server host (which is separate from the worker host). I don't believe I am mistaken in that workers can use the variables defined there? I have been using it for some time (in particular for repository-based tests) and thought it might still be possible to use it in an interactive test.
As mentioned originally, I did have some success doing this, but it appears inconsistent. I was wondering if I could somehow get it to work or if there was an alternative? I am trying to avoid using an overlay, for various reasons, but if it is totally necessary to use it then that isn't a major issue.
The images..image...headers in deploy you show, does it allow the passing of a username and password instead? As well, one or both pieces of information in the form of a variable rather than raw/hardcoded into the job?
Regards, Michael
On Sun, May 11, 2025 at 8:54 PM Michael Peddie michael.peddie@gallagher.com wrote:
Hi Milosz,
I am defining the variable in the env.yaml found in /etc/lava-server on the lava server host (which is separate from the worker host). I don't believe I am mistaken in that workers can use the variables defined there? I have been using it for some time (in particular for repository-based tests) and thought it might still be possible to use it in an interactive test.
you're right. I didn't understand it from your initial email.
As mentioned originally, I did have some success doing this, but it appears inconsistent. I was wondering if I could somehow get it to work or if there was an alternative? I am trying to avoid using an overlay, for various reasons, but if it is totally necessary to use it then that isn't a major issue.
environment options are passed to lava-run: https://gitlab.com/lava/lava/-/blob/master/lava/dispatcher/lava-run?ref_type... They may not be used where you expect them.
The images..image...headers in deploy you show, does it allow the passing of a username and password instead? As well, one or both pieces of information in the form of a variable rather than raw/hardcoded into the job?
Yes, works for basic authentication as well. You need to encode it with base64 as described here: https://www.debugbear.com/basic-auth-header-generator
It assumes the webserver recognizes the Authorization header.
Best Regards, Milosz
Thank you for the clarification, and providing further information on the header stuff.
I haven't been able to find anything in the documentation in detail regarding that, only stuff in the tftp deploy under ramdisk, but I get a warning on job validate about valid values (not a valid value @ data['actions[0]']['deploy']['tftp']['ramdisk']['header']) despite setting it up to look like what you showed previously. Even then, it isn't one of those files I wanted to download but an additional one to be used in my tests.
So, I tried using the download deploy method but that returns a warning on extra keys (extra keys not allowed @ data['actions[0]']['deploy']['download']['images']['somefile']['header']). Is there any particular method that is supposed to work? And that allows the download of arbitrary files? I'm not sure if it's relevant/necessary but I am running 2025.02, in case that somehow has any impact.
Best regards, Michael
On Mon, May 12, 2025 at 8:34 PM Michael Peddie michael.peddie@gallagher.com wrote:
Thank you for the clarification, and providing further information on the header stuff.
I haven't been able to find anything in the documentation in detail regarding that, only stuff in the tftp deploy under ramdisk, but I get a warning on job validate about valid values (not a valid value @ data['actions[0]']['deploy']['tftp']['ramdisk']['header'])
it's headers not header.
despite setting it up to look like what you showed previously. Even then, it isn't one of those files I wanted to download but an additional one to be used in my tests.
So, I tried using the download deploy method but that returns a warning on extra keys (extra keys not allowed @ data['actions[0]']['deploy']['download']['images']['somefile']['header']). Is there any particular method that is supposed to work? And that allows the download of arbitrary files? I'm not sure if it's relevant/necessary but I am running 2025.02, in case that somehow has any impact.
It's headers. Here is the schema: https://gitlab.com/lava/lava/-/blob/master/lava_common/schemas/deploy/__init...
It would be much easier if you could share your job definitions.
Best Regards, Milosz
Thank you for the correction, a stupid mistake on my part. The job now validates and runs. This is the gist of my job as it is now (with the headers download): device_type: mydut job_name: interactive test
context: lava_test_results_dir: /tmp/lava-%s
timeouts: job: minutes: 25 action: minutes: 20 connection: minutes: 5 priority: medium visibility: public
actions: - deploy: timeout: minutes: 5 to: download images: file: headers: Authentication: TOKEN url: https://artifactory.com/artifactory/path/to/myfile.tar.gz
- boot: timeout: minutes: 5 method: minimal prompts: ["# $"] auto_login: login_prompt: "login:" username: root
- test: timeout: minutes: 10 interactive: - name: smoke-test prompts: ["# $"] echo: discard script: - name: set-vars command: export SCRIPT="file.tar.gz" tests="smoke" - name: extract-wget command: "cd / ; tar -C /tmp/ -xzf /data/wget.tar.gz ; if [ -e /tmp/wget/libuuid.so.1 ]; then export LD_PRELOAD=/tmp/wget/libuuid.so.1; fi ; cd /tmp/" - command: echo '/tmp/wget/wget -P /tmp/ -nv --no-check-certificate --user=username --password=${ART_PASS} "$1"' > /tmp/download.sh - command: chmod +x /tmp/download.sh - command: /tmp/download.sh "https://artifactory/artifactory/path/to/some/%24SCRIPT" ; rm /tmp/download.sh name: download-scripts - command: tar -C /tmp/ -xzf /tmp/"$SCRIPT" ; chmod +x /tmp/scripts/*.sh ; chmod +x /tmp/scripts/*/*.sh ; cd /tmp/scripts/ name: extract-scripts - command: cat "$tests".sh | tr -d '\015' > temp.sh ; chmod +x temp.sh ; rm "$tests".sh ; mv temp.sh "$tests".sh - command: for dir in */; do for script in "$dir"*.sh; do cat "$script" | tr -d '\015' > temp.sh ; chmod +x temp.sh ; rm "$script" ; mv temp.sh "$script"; done; done - name: run-tests command: . /tmp/scripts/"$tests".sh -f bar -b foo || echo "$?" failures: - message: "[uU]sage:" exception: TestError error: "Incorrect script inputs" - message: "^1$" exception: TestError error: "A test has failed" - message: "[fF]ailed" exception: TestError error: "An error occurred during execution"
I don't think transfer_overlay would work to move the downloaded file over from the worker (since no overlay is created), would I be able to assume I can access downloaded files similarly to during that process? Or is there another method to move them over? Or would a deploy method change instead be recommended?
Best regards, Michael
On Mon, May 12, 2025 at 9:26 PM Michael Peddie michael.peddie@gallagher.com wrote:
Thank you for the correction, a stupid mistake on my part. The job now validates and runs. This is the gist of my job as it is now (with the headers download): device_type: mydut job_name: interactive test
context: lava_test_results_dir: /tmp/lava-%s
timeouts: job: minutes: 25 action: minutes: 20 connection: minutes: 5 priority: medium visibility: public
actions:
deploy: timeout: minutes: 5 to: download images: file: headers: Authentication: TOKEN url: https://artifactory.com/artifactory/path/to/myfile.tar.gz
boot: timeout: minutes: 5 method: minimal prompts: ["# $"] auto_login: login_prompt: "login:" username: root
test: timeout: minutes: 10 interactive:
- name: smoke-test prompts: ["# $"] echo: discard script:
- name: set-vars command: export SCRIPT="file.tar.gz" tests="smoke"
- name: extract-wget command: "cd / ; tar -C /tmp/ -xzf /data/wget.tar.gz ; if [ -e /tmp/wget/libuuid.so.1 ]; then export LD_PRELOAD=/tmp/wget/libuuid.so.1; fi ; cd /tmp/"
- command: echo '/tmp/wget/wget -P /tmp/ -nv --no-check-certificate --user=username --password=${ART_PASS} "$1"' > /tmp/download.sh
- command: chmod +x /tmp/download.sh
- command: /tmp/download.sh "https://artifactory/artifactory/path/to/some/%24SCRIPT" ; rm /tmp/download.sh name: download-scripts
- command: tar -C /tmp/ -xzf /tmp/"$SCRIPT" ; chmod +x /tmp/scripts/*.sh ; chmod +x /tmp/scripts/*/*.sh ; cd /tmp/scripts/ name: extract-scripts
- command: cat "$tests".sh | tr -d '\015' > temp.sh ; chmod +x temp.sh ; rm "$tests".sh ; mv temp.sh "$tests".sh
- command: for dir in */; do for script in "$dir"*.sh; do cat "$script" | tr -d '\015' > temp.sh ; chmod +x temp.sh ; rm "$script" ; mv temp.sh "$script"; done; done
- name: run-tests command: . /tmp/scripts/"$tests".sh -f bar -b foo || echo "$?" failures:
- message: "[uU]sage:" exception: TestError error: "Incorrect script inputs"
- message: "^1$" exception: TestError error: "A test has failed"
- message: "[fF]ailed" exception: TestError error: "An error occurred during execution"
I don't think transfer_overlay would work to move the downloaded file over from the worker (since no overlay is created), would I be able to assume I can access downloaded files similarly to during that process? Or is there another method to move them over? Or would a deploy method change instead be recommended?
This was my first question when I saw your job. Why are you doing it the hard way? :) You're basically reimplementing the transfer_overlay. Does your file only contain scripts? If yes, maybe you could host it in a git repository. This way you can use transfer_overlay and simplify your job. If you need some big binaries the story is not so simple. I'll try to figure out how to add an archive to overlay. It should be possible, but I don't have a ready example. From your earlier questions I remember that you can't modify the rootfs on the DUT. This would be probably the easiest, but I understand there are use cases that don't allow it.
Best Regards, Milosz
Haha, I understand that much myself. For internal reasons, I have been instructed to do it this way, though I am completely aware of and familiar with the things LAVA has in place to achieve the same tasks.
The job as written there is to download a set of framework scripts, so that depending on the tests variable and options provided in the final command, it does different things. In that version it will simply do smoke tests, but it could also be given options telling it to download some file(s), which can be quite large depending on the purpose. Ideally the download of those files can be handled by the script(s) so that they can end up directly on the DUT and to simplify the information needed of test writers (just a version name instead of a whole path), but where it isn't possible we'll just have to settle.
Best regards, Michael
Hi,
I managed to get headers working for what I needed, but variables set in env.yaml don't substitute. Is there any changes I can make somewhere for that? Either in a job/device/worker def/config, or the source code? I did some looking at how it's done elsewhere but I got lost and confused so I've put it on hold to work on other tasks. Any help would be appreciated, even if it's to be told there's nothing to be done about it.
Best regards, Michael
On Wed, May 14, 2025 at 12:36 AM Michael Peddie michael.peddie@gallagher.com wrote:
Hi,
I managed to get headers working for what I needed, but variables set in env.yaml don't substitute. Is there any changes I can make somewhere for that? Either in a job/device/worker def/config, or the source code? I did some looking at how it's done elsewhere but I got lost and confused so I've put it on hold to work on other tasks. Any help would be appreciated, even if it's to be told there's nothing to be done about it.
Are you referring to storing the passwords as worker env variables on the server? I never tried that and I'm not sure this would work
Passwords for headers are stored in user's profile. This works for sure
Best Regards, Milosz
What does stored in the users profile mean? Sorry if that comes across as a stupid question, I can only think of the xmlrpc auth tokens and the regular auth tokens only visible in the admin page, which technically cannot have customised values without the use of a cli. If that isn't what you're referring to, then is there something I missed? I couldn't find anything else like that, not in the documentation or anything.
Regarding the modifications to use the worker environment variables, I added a few simple lines to download.py (https://gitlab.com/lava/lava/-/blob/master/lava_dispatcher/actions/deploy/do...), which are the following: tmp=[v for k, v in headers.items()] for val in tmp: self.logger.debug("SOMEVAL: %s" % str(os.path.expandvars(val)))
I just put them into the validation stage of the HttpDownload action, to test the output, and it appears to work just like it does in other tasks where it's performed (like in vcs.py in lava_dispatcher/utils/). For now I might just put them into the actual download stage so that they can be used as per my intention, and perhaps another time look into other solutions.
Best regards, Michael
On Wed, May 14, 2025 at 8:26 PM Michael Peddie michael.peddie@gallagher.com wrote:
What does stored in the users profile mean? Sorry if that comes across as a stupid question, I can only think of the xmlrpc auth tokens and the regular auth tokens only visible in the admin page, which technically cannot have customised values without the use of a cli. If that isn't what you're referring to, then is there something I missed? I couldn't find anything else like that, not in the documentation or anything.
You can see the "remote artifact tokens" when you go to the me/ link in your instance. This is also available in admin interface (auth/user/<id>) at the bottom of the page. I don't think there is an API for that.
Regarding the modifications to use the worker environment variables, I added a few simple lines to download.py (https://gitlab.com/lava/lava/-/blob/master/lava_dispatcher/actions/deploy/do...), which are the following: tmp=[v for k, v in headers.items()] for val in tmp: self.logger.debug("SOMEVAL: %s" % str(os.path.expandvars(val)))
I just put them into the validation stage of the HttpDownload action, to test the output, and it appears to work just like it does in other tasks where it's performed (like in vcs.py in lava_dispatcher/utils/). For now I might just put them into the actual download stage so that they can be used as per my intention, and perhaps another time look into other solutions.
Good job. Send it for review.
Best Regards, Milosz
lava-users@lists.lavasoftware.org
-
Michael Peddie -
Milosz Wasilewski