wf_set_key gives pop up message 'Keyring password'

[sofialafuente]

Hi I am having issues downloading data into a HPC. I do the following:

wf_set_key(user = "12345", key = key, service = "cds") It works perfect when I download to my local machine, but when I try to run this in the HPC I get the following:

Your keyring is locked please unlock with your keyring password! Keyring password:

I enter what I think is mykey but it gives me the following error:

Error: yml must be a named list of length 3 with entries ‘c’, ‘keyring_info’, ‘items’

I tried entering:

user, key, cds and many other things but the problem keeps happening. Any help would be appreciated.

[khufkens]

Use file based keychain management, as described here:

https://github.com/bluegreen-labs/ecmwfr#file-based-keychains

[sofialafuente]

That worked, thank you so much!

[khufkens]

Sorry about the slow replies, busy days. Happy hacking

[BlaiseKelly]

Is it possible to expand on this a little. I added options(keyring_backend="file") but get the following:

Error in b__file_set_keyring_pass(self, private, key, keyring) : 
  Aborted setting keyring password
Calls: wf_set_key ... b_file_keyring_unlock -> <Anonymous> -> b__file_set_keyring_pass
Execution halted

should have a separate file? and should 'file' be replaced by the name of that? What should be in the file, the key? Like this user I have had this working on windows system for many years but am now running on a Headless linux system.

[khufkens]

The procedure is as follows:

To install the key:

# on a linux system call before each script (or put it in the startup setting of your R session)
# this will state that the key should be stored and retrieved from file
options(keyring_backend="file") 

# set your key after enabling this option
wf_set_key(user = "1234",
            key = "abcd1234-foo-bar-98765431-XXXXXXXXXX",
            service = "cds"
)

To run a script:

# on a linux system call before each script (or put it in the startup setting of your R session)
# this will state that the key should be stored and retrieved from file
options(keyring_backend="file") 

request <- list(
    code = code,
    kwargs = list(
      var = "Near-Surface Air Temperature",
      lat = 50,
      lon = 20
    ),
    workflow_name = "plot_time_series",
    target = "test.nc"
  )

  # Execute the script via the API
  # as you would for a data request
  wf_request(
      request,
      user = "1234"
    )

[zackarno]

Hi, thanks for the above information which I am trying to follow. I am wondering how this would work on a GitHub Action with an Ubuntu runner? where does the "file" get stored and accessed?

[khufkens]

A runner is a virtual machine which does not retain it state (well there are ways to buffer, but I won't go into this).

What you do is you setup an environmental variable with your API key (you should never put it in a repo in plain text, as this is bad practice). You set the key as per usual, at the start of every runner session, using the environmental variable. Validate if it works. You can then run the remaining script.

Be careful what you set up, runners cost money and you don't want to leverage this too much (claiming "free" resources and then spoiling the game for others). Github has slowly starting to decrease the capacity on the free tier due to in part the runner (free compute) time.

Long short, I would not run jobs on github. I do small queries for code coverage but that's about the scope you should expect.

[zackarno]

Thank you very much for the quick reply!

Yes I've been authenticating w/ env variables like so:

ecmwfr::wf_set_key(
  user = Sys.getenv("ECMWF_USER_UID"),
  key = Sys.getenv("ECMWF_USER_KEY"),
  service = "cds"
)

The GH repo of course has these stored as env secrets and the workflow yaml provides a step to access these.

I've tried the above call both with and without setting option first with:

options(keyring_backend="file")

each time the action returns the following error:

#> Error in b__file_keyring_create_direct(self, private, keyring, password,  : 
#>  Aborted creating keyring
#> Calls: source ... b_file_keyring_create -> <Anonymous> -> b__file_keyring_create_direct
#> Execution halted

Any idea what step I am missing?

Also thanks a lot for the cautionary warning on using GHA for jobs. This is a not a large call. It only returns a 3-4 files under 10 kb each and will ultimately only run 1x month. So I am thinking it should be okay at least for a proof of concept?

[khufkens]

Add this (see test routines package):

# set options
options(keyring_backend="file")

# spoof keyring
if(!("ecmwfr" %in% keyring::keyring_list()$keyring)){
  keyring::keyring_create("ecmwfr", password = "test")
}

[zackarno]

That seems to have worked - amazing!

Do you have a link for "test routines package" - i'm not sure what you are referring to.

Thanks a million!!

[khufkens]

Unit tests of the package

https://github.com/bluegreen-labs/ecmwfr/tree/master/tests/testthat

Do me favour if you can and reference the package in publications, helps to keep the business afloat

[zackarno]

💯 !