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

RHEL8 Workstation Installation requirements #13

Open
gilesknap opened this issue Jun 27, 2022 · 6 comments
Open

RHEL8 Workstation Installation requirements #13

gilesknap opened this issue Jun 27, 2022 · 6 comments
Assignees

Comments

@gilesknap
Copy link
Contributor

@aawdls

We need a couple of things to add to the list for RHEL 8 installation:

  • crun
  • a couple of RHEL 7 library versions
    • libcrypto.so.10
    • libssl.so.10

The libraries make dls-python3 work on RHEL8 and the python3 workflow should then be good to go.

@aawdls
Copy link
Contributor

aawdls commented Jun 30, 2022

The libraries make dls-python3 work on RHEL8 and the python3 workflow should then be good to go.

I'll make sure these are in the list.

Can you explain what you mean by the python3 workflow? Is it the one I currently understand which is "release from the devcontainer, run natively" or something else?

@gilesknap
Copy link
Contributor Author

Python 3 pipenv and python3 itself work natively on RHEL8 workstation with those 2 libraries. I guess saying the workflow works was incorrect since I'm sure dls-release will not work without the container.

But python3 apps will run - even e.g. dls-pmac-control.py

@gilesknap
Copy link
Contributor Author

@aawdls Do you think we should put VSCode on this list?

@aawdls
Copy link
Contributor

aawdls commented Jul 13, 2022

Yes. There are the installations in /dls_sw/apps maintained by someone (unknown to me), but we need to decide whether we want to continue using these or a system package.

@MJGaughran
Copy link

I think it is more appropriate to leave this kind of thing to the user.

It is straightforward to install system packages. It might also make sense to assign someone (formally) to regularly update the vscode module, as it is a tool used by many people at Diamond.

I think we are trying to move away from standard installs of tools etc, and allow people to opt-in to them. This is in that category. Standard installs should be reserved for basic functionality, in my view.

@gilesknap
Copy link
Contributor Author

@MJGaughran re installing system packages. Some of us with pcXXXX machines can do that but those with wsXXXX cannot and the distribution seems random. For your policy to work we need to make sure people get yum rights.

Or am I misunderstanding you?

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

3 participants