They are test boxes, so although I do have access to them, I cannot make any module changes. I can only work with what's already there. I thought of putting all the bash commands in a bash script and just running that, but I assign the results of these commands to various perl variables, so I don't think that it's feasible (without a lot of work). I'm getting the feeling that I will have to re-write my subroutines. Would love to know if anyone has made it work though.
| [reply] |
I should note that I thought of using local::lib to keep modules private and without needing root access, but I'm pretty wary of tampering with the test environment in any way. The ideal situation is to have a persistent ssh session (persistent even when calling a subroutine) which I can tell it to close when I want:
1) open ssh session
2) call subroutine (subroutine should run within the ssh session, not on the local system)
3) close ssh session
I will be indebted to anyone who has done this or can point me in a good direction.
| [reply] |
I'm no expert, but it doesn't sound possible to me. Here's another idea though. What if on the test boxes you write a CGI program that outputs the data in some format, such as CSV or XML. Then the other machine uses LWP to retrieve the data and run it through the subroutines? You could use IO::Socket if you really wanted to get fancy, but conceptually it's the same thing. That is, you are retrieving the data from one box, parsing it on another.
| [reply] |
You're hoping to run some code (whether you call it a 'subroutine' or not doesn't matter) on a remote system, but have it call other code (modules) back on the local system somehow. I don't think that's possible, short of mounting the local system on the remote via NFS or something, which would be a lot sketchier than the reasonable options you're saying wouldn't be allowed.
Using local::lib seems like the most sensible solution, assuming you can't get the server admins to install the modules for you.
| [reply] |