Automatically accepting the license agreement? (y/N):

CubitVersion: 21.05
Platform: Debian 10.10 inside a Docker container

Issue

When running in batch mode the need to accepting the license agreement then appears and requires a yes or no to be input by the user.

Do you accept the license agreement? (y/N):

I can’t see a method of the user inputting this yes no when running in batch mode. For example it is not possible in CI based systems or other batch processes.

What can we help with?

So I was wondering if the acceptance can be automated. Perhaps by putting a fie somewhere or on the Cubit init?

Many thanks

I think importing with Python might actually get around this requirement to input y/n. I am continuing to look into this

@jshimwell

You are correct that this is stored in the Cubit.ini file. If you’ve read and accept the license agreement, you can store this information under the [clarofw] block:

[clarofw]
eula=true
1 Like

Thanks Greg this will help out on the CI front. Cheers

Just for anyone else reading this and searching the /opt/Coreform directory on Ubuntu for the Cubit.ini file I just found it in

~/.config/Coreform/Cubit.ini

1 Like

I’ve found the Cubit.ini file on my machine and got the eula=true to work in there.

When installing Cubit on a Docker image it appears that Cubit doesn’t make a ~/.config/Coreform/Cubit.ini file or even the folder ~/.config/Coreform

So I’ve tried making the folder and file with the [clarofw]\neula=true but I’m still being prompted to accept the agreement.

Wondering if the Cubit.ini behave differently on Docker where the home dir is /

Or perhaps I Cubit looks for Cubit.ini in a few locations?

You can try piping the yes utility through the installer, which is available on Linux and macOS:

yes | installer_command

or if that didn’t work, you can fake a tty with expect, which is available from Tcl or Python.

@jshimwell You’re better off making a user inside the Docker container, there’s a few things inside Cubit (like OpenMPI) that strongly dislike being root. We do it like this:

RUN useradd --create-home --shell /bin/bash coreform
USER coreform
WORKDIR /home/coreform

We do this at the very end of the Dockerfile, so everything that requires root for setup is done under root, but when the container starts up it’ll start as the coreform user. The Cubit.ini file will then be in /home/coreform/.config/Coreform/Cubit.ini as expected.

Thanks for your answers, I’ve been trying things but no luck currently.

I did find out that the directory /home/username/.config/Coreform appears to not be made when the coreform is installed with dpkg -i coreform-cubit-2021.5.deb but it is made when coreform is run for the first time.

I’ve made a minimal example of just what I’m trying to do and added CI so that the error messages can be seen.

Screenshot from 2021-08-23 21-05-30

I’m hoping to run this as a free cubit learn license so I had assumed it does not need a .lic file

In the line where you write to license.lic in the Dockerfile, write instead to cubit-learn.lic. This will be changing in the future, by the way, but in 2021.5 that’ll work.

Thanks for your help, I tried but perhaps i didn’t do that quite correctly? I changed the license filename in the line 61 where I write out a license file to cubit-learn.lic and reran the CI

commit

CI gave the same result

Try exporting the environment variable CUBIT_VERBOSE=5. This won’t fix the issue but it’ll write a lot more output out about the licensing.

You should also be able to build the Dockerfile locally, then use docker run -it --rm <image name> /bin/bash to get a container instance with an interactive terminal you can you use to test things on your own without having to commit to git.

1 Like

Thanks for that CUBIT_VERBOSE=5 suggestion, as a result I noticed Cubit was looking for the lic file in the .config folder so I made the folder and moved the lic file there. I think the CI will past this time as I’ve tested it locally.

Interested to know what will change with the next release, will the cubit-learn.lic filename still work or perhaps any *.lic filename will work

Thanks for all the help

In future releases we plan to require a (recent) login to the user’s Coreform account - which will then be good for some period (e.g. seven days). This will only be for Learn licenses (and maybe trial licenses).

Would this work for you?

That sounds fine to me. I think that could also be a nice solution for users wanting to deploy cubit on an air gap system where the computer with Cubit installed can connect to the internet.

And just to clarify, paid licenses will have all options available to them:

  1. Cloud floating
  2. Internal floating
  3. Node-locked (non-networked / air-gapped)