Our group occasionally has a difficult time troubleshooting user specific issues with OOD. Every so often a user will launch an interactive app, usually a virtual desktop session, and it won’t launch, for whatever reason, we get asked why it won’t launch. After using OOD for awhile, we’ve gotten pretty good at figuring out some basic issues. But we still run into some issues that are tough to troubleshoot. For regular application troubleshooting, it’s easy enough to just sudo - $username but as far as I’m aware, something like that doesn’t exist in OOD. Am I correct in my understanding that it doesn’t exist or a feature like it doesn’t exist? I’ve looked around the discourse, but not heavily into the roadmap, but is something like this on the roadmap if it doesn’t already exist?
No and I kind of need the same functionality right now at our center.
But I don’t believe we’ll enable it any time soon, if at all. This is structural and by design. That is, all these Per user Nginx’s (PUNs) where meant to ensure you worked in your own space and with your own uid.
As suppport staff at OSC (and the world at large) though, we really rely on screen shots, logs from the jobs (in ~/ondemand/data/sys/...), and read only links in desktop sessions.
As suppport staff at OSC (and the world at large) though, we really rely on screen shots, logs from the jobs (in ~/ondemand/data/sys/... ), and read only links in desktop sessions.
This is what we do as well. It’s just tough when we have to have our users test again after we try something. And then it doesn’t work and we try something again and then we ask them to try it again and it doesn’t work. Rinse and repeat until it’s fixed. But I also understand why it’s designed the way it is.
We could probably launch a qsub job directly as the user from the command line that matches what OOD would launch if that’s where the issue is happening, right? Instead of the OOD interface, use the command line, which we can access as the user? I don’t totally understand all the things that could come from this, but this might give us something useful. In this specific instance the job almost immediately terminates.
There might be a way with an Apache rewrite rule to rewrite REMOTE_USER in Apache and force yourself to become someone else based on some condition. Because of how authentication works with OnDemand there is no real good way to become someone else. Most applications that allow user switching are responsible for user management but OnDemand relies on Apache. There maybe be tricks with ood_auth_map.mapfile too but nothing we’ve tested.
Our tech support scientists have also asked for this. I’ve recommended having the user share their view-only session and walk the support person through the problem, or to use some other form of screen sharing. It’s an inconvenience, sure, but it works fine and there’s probably more important stuff to worry about (unless there’s a use case I can’t think of).
I’ve recommended having the user share their view-only session and walk the support person through the problem, or to use some other form of screen sharing.
The problem we’ve ran into with the view-only sharing is that sometimes something in the user’s environment prevents sessions from even starting. So the view-only session doesn’t even get to the point of working.
Some other form of screen sharing might work. I’m not sure if it’s allowed in our environment. That might be something we look into.
Thanks for the feedback though, everyone. Good advice and it’s appreciated.