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

testdev script for testing on operation system #30

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

dehorsley
Copy link
Member

@dehorsley dehorsley commented Apr 16, 2020

This is a preliminary sketch of a utility to assist testing a development
version of the Field System on an operational machine without disturbing
the working system, as discussed in issue #21.

As it stands it is very basic and some experimentation and discussion is needed
to understand the use case(s).

Current assumptions:

  • User has root access via sudo
  • FS version to be tested is /usr2/fs-dev
  • st.default control files should be used

Outstanding issues & questions:

  • Should we protect the log directory? We could either mount a tmpfs or overlayfs here?
  • ditto proc
  • ditto control
  • how to handled st code? May need recompiling, so an overlayfs might be the way to go.
  • can this be done without sudo/root access? User namespaces should allow this but I had some quirk that stopped fsalloc from working.

@dehorsley dehorsley requested review from jfhquick and wehimwich April 16, 2020 10:02
@jfhquick
Copy link
Collaborator

This appears to work well as it is, but having to allow 'sudo unshare' is obviously a security hole that is very easy to exploit. Hopefully I will have time to play around with this and see if I can figure other ways to make it work,
Using this, I was able to have two different FS versions running side-by-side on the same machine at the same time quite happily (after overlaying /usr2/proc), but I didn't check to see what happened in station.log which is where the other contention would be.
This approach certianly show promise :)

@dehorsley
Copy link
Member Author

Right, I guess that's the kind of use case discussion I need. Security is of course relative :). My assumption was that the programmer/tester has root access via sudo.

Also, the reason I used sudo originally was to pass the xauth cookie through to the next user, but then I realised it's not necessary if you log back in as the user. I'm now not sure that needs to be in there.

@dehorsley
Copy link
Member Author

I guess @wehimwich needs to chime in here. He's the target user right now :)

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

Successfully merging this pull request may close these issues.

2 participants